search for: llvm_build_llvm_dylib

Hi, In SUSE we have recently switched from building LLVM as multiple shared libraries (using BUILD_SHARED_LIBS) to building it as a single shared library (using LLVM_BUILD_LLVM_DYLIB). The multiple shared libraries build was causing issues and apparently it is only meant for LLVM developers. Our guidelines prohibit linking against static libraries unless there is no other option. After this change, some external tools failed building because they try to link against librar...

...r LLVM 8. I only need the components requested here https://gitlab.freedesktop.org/mesa/mesa/blob/master/scons/llvm.py#L103 After reading https://llvm.org/devmtg/2015-04/slides/eurollvm-2015-build.pdf and https://llvm.org/docs/CMake.html I found these options to be relevant: LLVM_DYLIB_COMPONENTS, LLVM_BUILD_LLVM_DYLIB, LLVM_LINK_LLVM_DYLIB, LLVM_BUILD_TOOLS and LLVM_INCLUDE_TOOLS. Unfortunately LLVM_DYLIB_COMPONENTS depends on LLVM_BUILD_LLVM_DYLIB which doesn't support MSVC, I can turn off LLVM_BUILD_TOOLS and LLVM_INCLUDE_TOOLS if I figure out how to filter unneeded components as I would no longer need llv...

...g> wrote: >>>> Thanks - I'll try this tonight. >>>> >>>> Assuming it works, should these variables be added to the docs at >>>> http://llvm.org/docs/CMake.html ? >>> >>> Yes. >> >> It probably makes sense to add LLVM_BUILD_LLVM_DYLIB, but I would discourage adding BUILD_SHARED_LIBS to that document. BUILD_SHARED_LIBS is rarely what people actually want, and a lot of people gravitate to it because the wording is similar to the autoconf —enable-shared flag. > > Considering that BUILD_SHARED_LIBS is rarely what people want,...

On 10 June 2017 at 21:04, biologi spm via llvm-dev <llvm-dev at lists.llvm.org> wrote: > clang.exe, clang++.exe, clang-cl.exe, clang-cl.exe and > msbuild-bin/cl.exe are each 37MB, but they serve almost the same > purpose, just receive different flavours of command flags. On Unix systems these are all symlinks and so essentially free. I hear Windows doesn't cope well with that

...port. The two main issues you’re being impacted by are 25664 and 25665. I suspect that you are hitting 25664 because you’re setting LLVM_ENABLE_SHARED=On, which probably doesn’t do what you think it does. There was no equivalent of that flag in autoconf. The autoconf —enable-shared option maps to LLVM_BUILD_LLVM_DYLIB=On in CMake. For 25665, we will need to add an option to skip generating targets for libcxx’s library. I can work that up today or tomorrow. Also, make sure you are setting LLVM_BUILD_EXTERNAL_COMPILER_RT=On. If you don’t set that you’re not building libclang_rt with the just-built compiler. If...

I am trying to build Clang/LLVM with -DLLVM_BUILD_LLVM_DYLIB=ON and -DLLVM_LINK_LLVM_DYLIB=ON to reduce the size of toolchain. I am getting LINK error 1181 about `lib\LLVM.lib` not found. After investigating, `lib\LLVM.lib` is supposed to be produced along with `bin\LLVM.dll`. `bin\LLVM.dll` is indeed produced, but it does not contain any exported symbols (...

And again... LLVM_BUILD_LLVM_DYLIB:BOOL=ON LLVM_LINK_LLVM_DYLIB:BOOL=ON This one is the good one... maybe. On Tue, Sep 6, 2016 at 11:35 PM, Alexandre Isoard < alexandre.isoard at gmail.com> wrote: > That is because I mistyped it: > LLVM_ENABLE_LLVM_DYLIB:BOOL=ON > LLVM_LINK_LLVM_DYLIB:BOOL=ON > > On Tue, Sep...

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

Hi, the first question is addressed both to llvm-dev and gentoo-dev. The second one is Gentoo specific. Is there any possibility to build LLVM both as static and shared libraries? What I see currently is that our ebuild makes LLVM to build shared libs unconditionally. Is there a possibility (if it is impossible to build both lib types) to at least give to user control on what kind of libs he

...ris, > > Thanks for working on this. I haven't been following LLVM for a few > months and in that time it seems support for building a monolithic > shared library has been added which is great! I've been looking over > it and I have a few questions/comments. > > * The LLVM_BUILD_LLVM_DYLIB flag isn't document. I've attached a patch for this. Patch LGTM. Later today I will also add this to my patches currently under review: http://reviews.llvm.org/D8046 <http://reviews.llvm.org/D8046> > > * I'm not very familiar with export lists so sorry if this is a dumb &...

There has been a lot of progress since I first sent out an email recapping the status of replacing autoconf, so I thought I’d send an update. Completed: * Bug 15493 - No option to build shared libLLVM-version.so in CMake * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable * Bug 18722 - Option to use CMake with libc++ to compile clang * Bug 21560 - Add support to cmake for

...11:24, David Jones via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Thanks - I'll try this tonight. >> >> Assuming it works, should these variables be added to the docs at >> http://llvm.org/docs/CMake.html ? > > Yes. It probably makes sense to add LLVM_BUILD_LLVM_DYLIB, but I would discourage adding BUILD_SHARED_LIBS to that document. BUILD_SHARED_LIBS is rarely what people actually want, and a lot of people gravitate to it because the wording is similar to the autoconf —enable-shared flag. > > We should probably be updating [1] too given that this docume...

...sioned libLLVMFooBar.so.3.7 and not against the unversioned library. This way when we ship the new libLLVM 3.8 old application will have to be recompiled to correctly link against the new LLVM LLVM 3.7 and before did this correctly and 3.8 should not break this. As I said in another mail I tried -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON but it's not currently usable as it is. Thanks, ismail

Hi, On Tue, Jan 19, 2016 at 8:09 PM, Chris Bieneman <beanz at apple.com> wrote: > I think the right solution here is to fix LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB (which should work) rather than fixing BUILD_SHARED_LIBS which was never intended to work for this use case. > > Either way, patches welcome. This seems to be due to your commit http://reviews.llvm.org/D13841 , the problem is I don't get properly versioned symlin...

my build environment: Win7 x64 VStudio 2017 Community Edition 15.8.4 (latest) CMake 3.12.1 (x86) git 2.19.0 (latest, x64) Python 2.7.2 (x86) my build steps: open VS2017 x64 developer command prompt cd D:\projects\fun\jit_tests mkdir llvm cd llvm git clone https://github.com/llvm-mirror/llvm mkdir llvm-build cd llvm-build cmake -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON

...ts.llvm.org> wrote: >> >> Thanks - I'll try this tonight. >> >> Assuming it works, should these variables be added to the docs at >> http://llvm.org/docs/CMake.html ? >> >> >> Yes. >> >> >> It probably makes sense to add LLVM_BUILD_LLVM_DYLIB, but I would discourage >> adding BUILD_SHARED_LIBS to that document. BUILD_SHARED_LIBS is rarely what >> people actually want, and a lot of people gravitate to it because the >> wording is similar to the autoconf —enable-shared flag. >> >> >> Considering that...

...in this area recently I thought I’d take a minute to explain the current state of things. Historically LLVM’s CMake build system has been able to produce shared libraries for each of the llvm static libraries. My patch (r220490) added the llvm-shlib tool to the CMake build system. You can now set LLVM_BUILD_LLVM_DYLIB=On on the CMake command line to generate a single libLLVM.dylib with a default set of LLVM libraries included. Tom, I’m really curious if this is close to meeting your needs. I’m guessing we probably need to add the version number to the library. Anything else? James, you commented that you like...

Hi, For lllvm 3.7 and before BUILD_SHARED_LIBS=ON would produce versioned shared libs like libLLVMLTO.so (symlink) libLLVMLTO.so.3.7 (symlink) libLLVMLTO.so.3.7.0 (real file) now it just builds an unversioned libLLVMLTO.so file which I believe is a problem because when a program links to llvm it generates a runtime dependency on libLLVMLTO.so instead of libLLVMLTO.so.3.7.0 which will break

On Tue, Sep 6, 2016 at 3:05 PM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > LLVM_ENABLE_DYLIB Where/when/how do you specify LLVM_ENABLE_DYLIB and LLVM_LINK_DYLIB? I tried the following on the cmake command line: $ cmake -G Ninja .. -DCMAKE_INSTALL_PREFIX=/home/wink/opt/llvm -DLLVM_ENABLE_DYLIB=true -DLLVM_LINK_DYLIB=true And got: ... -- Performing Test

...amp; "Duplicate option categories"' failed. [1] 25383 abort (core dumped) lld λ lldb-server : CommandLine Error: Option 'debug' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options llvm is built with: cmake -G "Ninja" \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DCMAKE_INSTALL_PREFIX=/usr \ -DLLVM_LIBDIR_SUFFIX=64 \ -DCMAKE_C_FLAGS="-fuse-ld=gold -fPIC" \ -DCMAKE_CXX_FLAGS="-fuse-ld=gold -fPIC" \ -DLLVM_REQUIRES_RTTI=ON \ -DLLVM_ENABLE_...