search for: build_shared_libs

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. All I get is bare libLLVMFooBar.so files.

...his 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, wouldn’t it make sense to document it to explici...

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

Hi, On Tue, Jan 19, 2016 at 7:18 PM, Chris Bieneman <beanz at apple.com> wrote: > The LLVM libraries are not API stable (especially not the ones you generate with BUILD_SHARED_LIBS). Those libraries are really not intended to ship. I know that's why I need them versioned. Currently we (openSUSE) ship libLLVM package which will install libLLVMFooBar.so.3.7 files and llvm-devel package will ship unversioned libLLVMFooBar.so. So, any application linking against LLVM genera...

...tionality between CMake and the autoconf build. > > In the autoconf build we didn't actually set the SOVERSION on libraries. Instead we include the version in the name of libLLVM, and we didn't version libLTO (except on Darwin). > > I believe we are coming back to the point that BUILD_SHARED_LIBS=On should never be used when building a distribution, so the libraries shouldn't be versioned. The only reason to use libLTO is if your system linker is slow and you want to improve iteration times. > > A clang built with BUILD_SHARED_LIBS=On will be significantly slower than one built ag...

On Thu, Jan 28, 2016 at 3:06 PM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > > > On 1/28/16 4:00 PM, Yin Ma via cfe-dev wrote: > >> Hi David, >> >> I assume you have a powerful machine. Our drive space is on network >> mounted >> >> machined by IT department. The machine is default Ubuntu setup with 8 >> cores. >>

...n CMake and the autoconf build. >> >> In the autoconf build we didn't actually set the SOVERSION on libraries. Instead we include the version in the name of libLLVM, and we didn't version libLTO (except on Darwin). >> >> I believe we are coming back to the point that BUILD_SHARED_LIBS=On should never be used when building a distribution, so the libraries shouldn't be versioned. The only reason to use libLTO is if your system linker is slow and you want to improve iteration times. >> >> A clang built with BUILD_SHARED_LIBS=On will be significantly slower than one...

...ebug 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 when a patch is > merged. Yesterday, I found the tip failed to build with ON. Today, tip is > O.K to build in shared linking. This is a different matter, and as David said, one that may not be *that* critical, given to the number of people that use shared libs on debug builds....

I got curious how the lld produced gnu hash tables compared to gold. To test that I timed "perf record ninja check-llvm" (just the lit run) in a BUILD_SHARED_LIBS build. The performance was almost identical, so I decided to try sysv versus gnu (both produced by lld). The results are interesting: % grep -v '^#' perf-gnu/perf.report-by-dso-sym | head 38.77% ld-2.24.so [.] do_lookup_x 8.08% ld-2.24.so...

...17G, shared build is only 1.5G. On a mainstream linux host machine with 12G memory, only -j1 can be used to finish final linking step. With -j8 the linux will link the linking. With 17G footprint, copying from build folder to install folder is also very slow. So it is very reasonable to set BUILD_SHARED_LIBS=ON as default for debug build because it would improve usability and performance. Thanks, Yin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160128/f1f3d6b4/attachment.html>

...question is clang-check-mac-libcxx-fixed-compilation-db.cpp which copies clang-check to a local directory to make sure clang can find libcxx via rpath. However, when built with shared libs, the copy of clang-check can't find any of it's libraries, so I'd like to either turn if off when BUILD_SHARED_LIBS=ON, or find a way to fix it. Thought about trying to use DYLD_LIBRARY_PATH, but don't think that's the correct approach. There are also a set of clang module tests that fail, as well as a few tools that build local without using llvm_add_library that I plan to fix, but I think this one is...

...d is showing huge advantage due to size reduction. I will try those two debug options to see how it works. Thanks, Yin From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Thursday, January 28, 2016 2:43 PM To: Yin Ma Cc: llvm-dev; cfe-dev Subject: Re: [cfe-dev] Proposal: Enable BUILD_SHARED_LIBS=ON by default for debug build. On Thu, Jan 28, 2016 at 2:34 PM, Yin Ma via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > wrote: Hello, I understand shared linked is currently a lot slower than static linked. However, for debug build, where spee...

...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 document talks > exclusively about compiling with th...

...ation now depends only on custom targets and custom commands associated with libraries on which the object’s target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets’ dependencies to link. With BUILD_SHARED_LIBS, compiling units don't wait for preceding shared libs. See also; http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux Regardless of BUILD_SHARED_LIBS, compile units in add_executable() don't wait for preceding libraries, but targets by add_dependencies(). It doesn't break anything in llv...

...) 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 -DLLVM_TARGETS_TO_BUILD=host -DLLVM_ENABLE_WARNINGS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_DOCS=OFF ../llvm cmake --build . produces these errors and warnings while building CMake Warning at CMakeLists.txt:29 (message):   Visual Studio generators use the x8...

....so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fe47d730000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe47d52c000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe47d224000) /lib64/ld-linux-x86-64.so.2 (0x00007fe480aa5000) Using CMake with BUILD_SHARED_LIBS, it looks like this: http://paste.ubuntu.com/12205368/ (the fact that I used pastebin is a hint) The main difference is the many LLVM/Clang shared library dependencies, rather than just one. It's preferred that each shared library is packaged separately, but this would be a bit of a mainte...

Dear all, while trying to build llvm with shared libraries using GCC (tested both in Ubuntu 14.04 and Ubuntu 16.04) as in cmake -G Ninja -DBUILD_SHARED_LIBS=ON I run into the following link error lib/Transforms/IPO/CMakeFiles/LLVMipo.dir/PartialInlining.cpp.o: In function `llvm::ForwardDominanceFrontierBase<llvm::BasicBlock>::ForwardDominanceFrontierBase()': <path>/llvm/include/llvm/Analysis/DominanceFrontier.h:122: undefined re...

...cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html> CMAKE_BUILD_TYPE¶. Specifies the build type on single-configuration generators. This statically specifies what build type (configuration) will be built in this build tree. cmake.org To build shared library you use the following flag: -DBUILD_SHARED_LIBS=ON https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html BUILD_SHARED_LIBS — CMake 3.14.1 Documentation<https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html> BUILD_SHARED_LIBS¶. Global flag to cause add_library() to create shared libraries if on.. If present and t...

...and custom commands associated with >> libraries on which the object’s target depends and no longer depends on the >> libraries themselves. Source files in dependent targets may now compile >> without waiting for their targets’ dependencies to link. >> >> With BUILD_SHARED_LIBS, compiling units don't wait for preceding shared >> libs. >> See also; http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux >> Regardless of BUILD_SHARED_LIBS, compile units in add_executable() don't >> wait for preceding libraries, >> but targets by add_dependen...

...y 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, wouldn’t it...