similar to: Building SVN head with CMake - shared libraries?

Thanks - I'll try this tonight. Assuming it works, should these variables be added to the docs at http://llvm.org/docs/CMake.html ? On Wed, Jan 13, 2016 at 10:26 PM, Andrew Wilkins <axwalk at gmail.com> wrote: > > > On Thu, 14 Jan 2016 at 11:02 David Jones via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Now that autoconf is going away soon, I

While considering statically linking against libc++ (and other runtime libraries from LLVM), I rebuilt LLVM 4.0 with -DBUILD_SHARED_LIBS=OFF. There are still some .so's in llvm/lib, and only one of them seems to exist exclusively as a DSO (libLTO). There's also livLLVMLTO.a, but I doubt LTO is used after linking a binary so this just looks odd to an uninformed LLVM outside and not

I just built a stage-1 compiler from the 3.9 release bits and built the lldb from head sources which worked fine. Let me try again using 3.9 build compiler to build 3.9 bits. Teresa On Tue, Sep 27, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Tue, Sep 27, 2016, 2:38 PM Carsten Mattner <carstenmattner at gmail.com> > wrote: > >> On

On Tue, Sep 27, 2016 at 11:17 PM, Teresa Johnson <tejohnson at google.com> wrote: > Sure, I will try this and let you know. Unfortunately, though, I > have another big work commitment that is going to eat up most of my > time through Thu, although I may be able to find some time to try > it. No worries, if I get around it before you do, I will :). > I think so - what is

On Tue, Sep 27, 2016 at 8:37 PM, Teresa Johnson <tejohnson at google.com> wrote: Just in case it's important, I'm using Arch Linux (and most Linux distros these days) CFLAGS/CPPFLAGS/LDFLAGS, which are as follows: $ grep FLAGS /etc/makepkg.conf CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"

Hi, Using master at b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8, I cannot build LLVM. I configured with: CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DBUILD_SHARED_LIBS=OFF \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \

I'm upgrading my application to use LLVM 3.7.1 instead of 3.5.1. On one of my regression tests I am getting an assertion: /home2/djones/llvm-3.7.1.src/lib/IR/Metadata.cpp:490: void llvm::MDNode::resolve(): Assertion `isUniqued() && "Expected this to be uniqued"' failed. This occurs when finalizing debug info prior to code generation: #4 0x00007ffff4520455 in

Thanks for your quick reply. I have also tried disabling build shared libs, specifying via "-DBUILD_SHARED_LIBS=OFF" in my cmake config line However I am getting the same exact error with this flag specified as well. Just an idea, would removing all llvm/clang instances/libs on my machine work? Do you know what the default location is of these shared/static llvm libraries that are

Isn't libc++.so dependent on libc++abi.so? On Mon, Mar 5, 2018 at 10:30 AM, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: > From what I can see all of the libraries without RPATH are runtime > libraries that are used by binaries compiled with Clang. I think they don't > have a dependency on other libraries in that directory, so what would be > the advantage of having

It was just brought to my attention that the RPATH configuration isn't uniform among the libraries produced by the release. Some use $ORIGIN../lib/ and others have none. Is this by design? It seems like it might be ideal for all of them to be configured the same way. If that makes sense I'll create a corresponding feature request. $ for f in

From what I can see all of the libraries without RPATH are runtime libraries that are used by binaries compiled with Clang. I think they don't have a dependency on other libraries in that directory, so what would be the advantage of having RPATH set on them? Regards, Jonas Am 2018-03-05 17:23, schrieb Brian Cain via llvm-dev: > It was just brought to my attention that the RPATH

Hello, Le 12/12/2016 à 18:29, Hans Wennborg a écrit : > +Sylvestre who knows about these things. > > On Thu, Dec 8, 2016 at 2:24 AM, Kris van Rens via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> L.S., >> >> I'm currently in the process of creating Debian packages for >> clang/llvm release 3.9.0. For this I'm using the steps as explained on

libc++.so should be a linker script that automatically pulls in libc++abi (see "Failed to read file header" in your output). And IIRC libc++abi is only one possible implementation that may be used by libc++, but I'm no expert here... Am 2018-03-05 17:33, schrieb Brian Cain: > Isn't libc++.so dependent on libc++abi.so? > > On Mon, Mar 5, 2018 at 10:30 AM, Jonas

Hi, I am a newbie in LLVM. I am very impressed with this forum and appreciate your help and time. I am trying to include llvm IR parser in my codebase, the way I wanna do is generate llvm's shared object (.so) file and use it in my project. So far I haven't been able to generate correct .so's. When I build a debug build with gmake (have llvm and clang in my sandbox), I get the

On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/19/2020 09:05 PM, Sedat Dilek wrote: > > Hi Tom, > > > > thanks and congrats for LLVM 10.0.1-rc1 release. > > > > [1] shows 2 assets. > > 10.0.0 RCs had a lot of more assets. > > I am missing the llvm-project-10.0.1rc1.tar.xz tarball. > > > > Will

Hi, I'm trying to use CallGraphSCCPass, but I keep getting a bus error. I can reproduce the problem quite easily using the lib/Transforms/Hello example. I simply mix in these changes: #include "llvm/CallGraphSCCPass.h" ... struct Hello : public CallGraphSCCPass { static char ID; // Pass identification, replacement for typeid Hello() : CallGraphSCCPass(&ID) {}

On Fri, Sep 30, 2016 at 10:19 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Fri, Sep 30, 2016 at 1:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > > > > > On Sep 30, 2016, at 12:57 PM, Carsten Mattner <carstenmattner at gmail.com> > > > wrote: > > > > > > On Fri, Sep 30, 2016 at 6:35 PM, Teresa

On Tue, Sep 27, 2016 at 6:33 PM, Teresa Johnson <tejohnson at google.com> wrote: > > I can't reproduce the failure. I am building with a clang built > Release from recent source as my stage-1 bootstrap compiler: > clang version 4.0.0 (trunk 282322) (llvm/trunk 282341) The clang I use was built from the 3.9 release branch: clang version 3.9.1 (branches/release_39

Hello, I've spent some time hacking up the Debian packaging to use CMake instead of autotools; it's still a work in progress, but it works. It's a bit of a mess, though, primarily because there are differences in the output of the CMake and autotools builds. On my Ubuntu machine, the dependencies for clang-3.6 look like this: $ ldd /usr/bin/clang-3.6 linux-vdso.so.1 =>

Hello, We are now facing a bug caused by the GVN pass, only part of the code was optimized. I have found that the problem is cause by an Limit in lib/Analysis/MemoryDependenceAnalysis.cpp 00055 static cl::opt<unsigned> BlockScanLimit( 00056 "memdep-block-scan-limit", cl::Hidden, cl::init(100), 00057 cl::desc("The number of instructions to scan in a block in