similar to: Why are LLVM releases statically linked against LLVM libraries?

On 3 Sep 2017, at 02:41, Will Dietz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I can speculate the reasons from a technical standpoint and by > inferring from commit history... > but curious if there's a better answer to be had? There’s a fairly noticeably performance improvement from static linking. I think last time I benchmarked it, building FreeBSD with

Hi I found basically all llvm libraries are statically linked into each executable and LLVMgold.so, This make the clang/llvm package larger and larger with a lot of duplicated code. If I build debug version, the disk space required is even larger. Is there any particular reason to keep doing this way? If we separate several shared libraries something like libclang.so, libllvm.so and let

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

Hey everyone, first of all I just wanted to say thanks :) I've been using libclang for building my own C/C++ IDE and its great. I have, however discovered a bug (which I already submitted on llvm bugzilla but I got the impression that no one reads that :)). If I try to use clang_parseTranslationUnit on this code below: int main() { return reinterpret_cast libclang crashes. This is the code

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

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

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

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

> 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

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 \

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:

> On Jun 14, 2017, at 2:47 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On 15 Jun 2017, at 6:50 AM, Louis Gerbarg <lgerbarg at apple.com <mailto:lgerbarg at apple.com>> wrote: >> >>> >>> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

On 02/05/2014 11:26, Adam Strzelecki wrote: >> It should be fixed. Can you confirm? > > Nope. Sorry. Still doesn't work here: > > Get:3 http://llvm.org/apt/trusty/ llvm-toolchain-trusty/main libllvm3.5 amd64 1:3.5~svn207822-1~exp1 [7,300 kB] > Get:4 http://llvm.org/apt/trusty/ llvm-toolchain-trusty/main llvm-3.5-runtime amd64 1:3.5~svn207822-1~exp1 [52.0 kB] > Get:5

Hi LLVMDev, There’s been a good bit of progress this month, and with the dev meeting later this week I thought I’d send out a second update. There are only two outstanding blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I would greatly appreciate if someone who works on Mips would take a look at PR 23947. The following issues have been marked as fixed since the last

> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Folks, > > I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working

On 06/21/2012 04:22 PM, Óscar Fuentes wrote: > About the "many features" that cmake lacks, can you provide a list, > please? Generally it works fairly well, but here are some differences to the autoconf-based build I noticed: - No 'make uninstall'. That is a real deal breaker if you want to quickly try a new LLVM version. I know that cmake doesn't provide this out of

Hi Folks, I have a question regarding LLD support for ld64 mach-o linker synthesised symbols. I did a quick search of the LLD source and I can not find support for them so before I start trying to use lld I thought I would ask. I have found a couple of cases where they are essential. i.e. where there is no other way to get the required information, such as getting the address of the mach-o