similar to: Why do we static link all llvm libraries in every executable?

Now that autoconf is going away soon, I figured I'd try building using CMake. I checked out llvm, cfe and lldb from the SVN server, and followed the basic build instructions. cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/tools/llvm/svn_head -DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON ../llvm Everything worked well, and in

On Fri, Jan 15, 2016 at 11:05 AM, Ismail Donmez <ismail at i10z.com> wrote: > Hi, > > On Fri, Jan 15, 2016 at 12:59 AM, Chris Bieneman <beanz at apple.com> wrote: >> I’m kinda scared that you’re using it. What are you trying to accomplish >> that you are using it? Generally having LLVM split among that many >> dynamically loaded libraries results in

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

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

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

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 =>

Hi folks, I’m trying to port some code built on top of LLVM/Clang to Windows, however I just discovered that the precompiled versions from releases.llvm.org are missing all the libLLVM* and libclang* dlls. Also, some tools (e.g. opt) are missing on Windows as well. I’m curious whether it’s a technical limitation (i.e. certain things don’t work on Windows), or something else? For the others out

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

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

Sincere question! I'm not at all suggesting this is the wrong choice or asking it to be defended, just explained :) Simply curious if anyone can speak as to the reasons for this and perhaps give a sense of how strong these reasons are or if they're just the tie-breaking reasons we came up with because hosting /both/ seemed silly :P. (or whatever the case may be) I'll note the build

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 \

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

Hello, I don't know how it happened, but recent Ubuntu builds have broken -dev packages, which contain same libraries as non-dev packages. dpkg: error processing archive /var/cache/apt/archives/libllvm3.5_1%3a3.5~svn207603-1~exp1_amd64.deb (--unpack): trying to overwrite '/usr/lib/llvm-3.5/lib/libLLVM-3.5.so', which is also in package llvm-3.5-dev 1:3.5~svn207603-1~exp1 dpkg:

Hi Yin, I second David's words. I use shared libs myself on debug builds, but static builds with gold on a local disk is pretty feasible. Before I used gold, I had to have 16GB of RAM on my laptop, now I need less than 8GB for static builds. On 28 January 2016 at 23:58, Yin Ma via cfe-dev <cfe-dev at lists.llvm.org> wrote: > It is O.K. I just hope BUILD_SHARED_LIBS=ON is tested

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

Hi everyone, I'm new to LLVM and I'm still trying to learn how to get everything up and running. I'm trying to use llvm-gcc with the gold plugin and it complains that it can't find LLVMgold.so. As a simple test case I wrote a very basic C file: --- main.c --- int main () { return 0; } ------ and compiled it with: $ llvm-gcc -use-gold-plugin main.c llvm-gcc:

Hi, unfortunately, my build somehow hangs when linking clang binary and my system is in an unusable state. My toolchain is clang-3.8, gold-1.11 and LLVMgold.so from binutils v2.26.1 (both selfmade) and LTO-flag is enabled. My buildsystem uses cmake-3.6.0 and ninja-1.7.1 (both prebuilt). I have 52 last steps left in my 3rd build. My Linux-kernel is v3.13.0-92 from official Ubuntu repositories.

In LTOCodeGenerator.cpp there are some options related to optimization remarks. On MacOS, I can pass in this option to enable them: -Wl,-mllvm,-lto-pass-remarks-output=remarks But on Linux using 2.29.1 binutils version of gold, I try this alternative: -Wl,--plugin-opt,-lto-pass-remarks-output=remarks But I get this error message: LLVMgold: Unknown command line argument

> On Jan 14, 2016, at 11:43 AM, Ismail Donmez <ismail at i10z.com> wrote: > > On Thu, Jan 14, 2016 at 9:31 PM, Chris Bieneman via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> On Jan 14, 2016, at 11:22 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >> On Jan 14, 2016, at 9:38

On 10/22/2011 01:12 AM, Luis D. Pedrosa wrote: > Hi everyone, > > I'm new to LLVM and I'm still trying to learn how to get everything up > and running. I'm trying to use llvm-gcc with the gold plugin and it > complains that it can't find LLVMgold.so. As a simple test case I > wrote a very basic C file: > --- main.c --- > int main () { > return