search for: llvm_link_llvm_dylib

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@...

...atch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the Support library dependency set from the 'required_libraries = Support' in llvm/utils/unittest/LLVMBuild.txt is not read it for LLVM_LINK_LLVM_DYLIB. The new patch modifies llvm_add_library() in cmake/modules/AddLLVM.cmake to manually set the LLVMBUILD_LIB_DEPS_gtest property to LLVM when LLVM_LINK_LLVM_DYLIB is set and the library name is gtest rather than read from the tools/llvm-config/LibraryDependencies.inc generated by llvm-build....

Hi all, I recently gave LLD a try and it definitely works fine. However one cannot build it together with LLVM_LINK_LLVM_DYLIB: ELF/Driver.cpp and ELF/DriverUtils.cpp pull in llvm/Support/CommandLine.h which defines the command line options so these global variables end up in libLLVM-4.0svn.so via liblldELF. If this shared library is then linked into bin/lld or bin/opt one gets errors because of "Option '...'...

...ecute the resulting binary which aborts with the mentioned error.However I don't use LLVM_ENABLE_PROJECTS, I don't know if that changes the way libLLVM-4.0svn.so is linked... Cheers,Jonas Am Freitag, den 06.01.2017, 13:44 +0900 schrieb Rui Ueyama: > Hi Hahnfeld, > I just compiled with LLVM_LINK_LLVM_DYLIB enabled [1] and build lld with `ninja lld`. It built fine. What am I missing? > > [1] $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_THREADS=On -DLLVM_ENABLE_LLD=true -DLLVM_LINK_LLVM_DYLIB=true -DLLVM_ENABLE_PROJECTS='clang;lld' ../llvm-project/llvm > > On Wed, Jan 4,...

...9;t use LLVM_ENABLE_PROJECTS, I don't know if that changes the >> way libLLVM-4.0svn.so is linked... >> >> Cheers, >> Jonas >> >> Am Freitag, den 06.01.2017, 13:44 +0900 schrieb Rui Ueyama: >> >> Hi Hahnfeld, >> >> I just compiled with LLVM_LINK_LLVM_DYLIB enabled [1] and build lld with >> `ninja lld`. It built fine. What am I missing? >> >> [1] $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_THREADS=On >> -DLLVM_ENABLE_LLD=true -DLLVM_LINK_LLVM_DYLIB=true >> -DLLVM_ENABLE_PROJECTS='clang;lld' ../llvm-proj...

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 6, 2016 at 11:31 PM, Wink Sav...

...ly slower than a clang built against static libraries. On Darwin process launch for a clang built against an LLVM dynamic library takes 2ms longer to launch than clang built against static libraries. > > The fix here is not to make BUILD_SHARED_LIBS work the way it used to. The fix is to make LLVM_LINK_LLVM_DYLIB work with out-of-tree builds. Since I am the only one complained about this so far, I'll revert this change locally for 3.8 packaging and work on getting LLVM_LINK_LLVM_DYLIB work as expected so we can use it for packaging 3.9. 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 symlinks even after install. Al...

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

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

...r than a clang built against static libraries. On Darwin process launch for a clang built against an LLVM dynamic library takes 2ms longer to launch than clang built against static libraries. >> >> The fix here is not to make BUILD_SHARED_LIBS work the way it used to. The fix is to make LLVM_LINK_LLVM_DYLIB work with out-of-tree builds. > > Since I am the only one complained about this so far, I'll revert this > change locally for 3.8 packaging and work on getting > LLVM_LINK_LLVM_DYLIB work as expected so we can use it for packaging > 3.9. Other than the darwin-specific name choic...

...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 llvm-config anymore. ---...

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

...e: >> I am trying to enable this on openSUSE but it seems to break >> standalone lldb (note that we don't ship static libs): >> >> cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ >> -DCMAKE_CXX_FLAGS=-stdlib=libc++ -DLLVM_BUILD_LLVM_DYLI >> B=ON -DLLVM_LINK_LLVM_DYLIB=ON -DCMAKE_INSTALL_PREFIX=/usr >> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_LIBDIR_SUFFIX=64 -DLLDB_PA >> TH_TO_LLVM_BUILD=/usr -DLLDB_PATH_TO_CLANG_BUILD=/usr >> -DLLVM_RUNTIME_OUTPUT_INTDIR=/home/abuild/rpmbuild/BUILD/lldb-3.8.0/buil >> d/bin -DLLVM_LIBRARY_OUTPUT_INTDIR=/h...

...rally having LLVM split among that many >> dynamically loaded libraries results in significant performance regressions. > > When we first switched to cmake it was the only option to produce > shared libraries, hence we went with it. I am testing with > -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON atm, and will let > you know if any problem arises. I am trying to enable this on openSUSE but it seems to break standalone lldb (note that we don't ship static libs): cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS=-stdlib=libc++ -DLLVM_BUILD_LLVM_DYLI B=O...

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

On 01/17/2016 02:53 PM, Dan Liew wrote: > @Brad: CC'ing you because I know you use > ``llvm_map_components_to_libnames()`` so you will likely have > something to say about it breaking. I'm using it in CastXML but that could easily be adapted to something different if needed. The larger concern is that that API is the documented way to use LLVM in an application with CMake so

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

On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that any symbols from libxar not explicitly used with in the object files of libLLVM.dylib are stripped out. This means that those additional symbols used by llvm-objdump aren't accessible from libLLVM.dylib'...

...ris Bieneman <beanz at apple.com> wrote: >> Jack, >> >> What version of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is being linked against -lxar when > -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib > is created with -Wl,-dead_strip such that any symbols from libxar not > explicitly used with in the object files of libLLVM.dylib are stripped > out. This means that those additional symbols used by llvm-objdump > aren't accessible fro...