I’d like to get libLLVM with the CMake build as well. But if I try -DBUILD_SHARED_LIBS=ON, lldb-server fails to link properly and I cannot install anything.
Is this a bug in the make scripts for lldb-server?
How can I get libLLVM.so in addition to liblldb.so?
I’d like to get libLLVM with the CMake build as well. But if I try -DBUILD_SHARED_LIBS=ON, lldb-server fails to link properly and I cannot install anything.
Is this a bug in the make scripts for lldb-server?
How can I get libLLVM.so in addition to liblldb.so?
-DBUILD_SHARED_LIBS=ON will give you shared libraries for each component (libLLVMSupport.so instead of libLLVMSupport.a, etc.)
What you want to set is -DLLVM_BUILD_LLVM_DYLIB=ON. For this to work, you must not set -DBUILD_SHARED_LIBS=ON.
If you also want all the tools (clang, llvm-*, etc.) to link against libLLVM.so, you’ll want to set -DLLVM_LINK_LLVM_DYLIB=ON, otherwise you’ll have libLLVM.so but the tools will be linked against the static libraries.
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 the Autoconf/Makefile build system.
Yes, we should update that too. I actually have been meaning to put a section up there documenting the Apple Clang packaging because that is almost entirely open source now. I’ll try to get that done this week.
We should probably be updating [1] too given that this document talks
exclusively about compiling with the Autoconf/Makefile build system.
Yes, we should update that too. I actually have been meaning to put a section up there documenting the Apple Clang packaging because that is almost entirely open source now. I’ll try to get that done this week.
Considering that BUILD_SHARED_LIBS is rarely what people want, wouldn’t it make sense to document it to explicitly discourage people from using it and avoid them surprising behavior?
(By the way, the name is quite tempting to be used wrongly, it would benefit a rename maybe).
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 explicitly discourage people from using it and avoid them surprising behavior?
Honestly, I’m not sure anyone actually wants that behavior, and I’d kinda like to remove the option entirely.
(By the way, the name is quite tempting to be used wrongly, it would benefit a rename maybe).
Yea, at the very least we need a rename. It also violates the ${Project}_* naming convention.
Do I understand it correctly that LLVM_BUILD_LLVM_DYLIB produces a one
big libLLVM.so and a lot of static libraries? Btw currently for
openSUSE builds we do utilize BUILD_SHARED_LIBS so please don't remove
it.
It is exactly what I want to have for debug builds. It means linking
moderately chunked blocks of code together and can even parallelize that
easily. I agree that it is not an end user option, but for developers it
is helpful exactly as it is.
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 explicitly discourage people from using it and
avoid them surprising behavior?
Honestly, I’m not sure anyone actually wants that behavior, and I’d kinda
like to remove the option entirely.
Do I understand it correctly that LLVM_BUILD_LLVM_DYLIB produces a one
big libLLVM.so and a lot of static libraries?
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 explicitly discourage people from using it and
avoid them surprising behavior?
Honestly, I’m not sure anyone actually wants that behavior, and I’d kinda
like to remove the option entirely.
Do I understand it correctly that LLVM_BUILD_LLVM_DYLIB produces a one
big libLLVM.so and a lot of static libraries? Btw currently for
openSUSE builds we do utilize BUILD_SHARED_LIBS so please don’t remove
it.
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 significant performance regressions.
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 explicitly discourage people from using it and avoid them surprising behavior?
Honestly, I’m not sure *anyone* actually wants that behavior, and I’d kinda like to remove the option entirely.
It is exactly what I want to have for debug builds. It means linking
moderately chunked blocks of code together and can even parallelize that
easily. I agree that it is not an end user option, but for developers it
is helpful exactly as it is.
+100, this speeds up incremental link tremendously.
And one more thing, in this setup llvm-config --libs lists static
libraries which is a no-go because Linux distros in the 99% of the
case want to ship only shared libraries.
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 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.
And one immediate “problem” shows up. I ended up with
Wrong because they’re inconsistent? libLLVM was changed recently (major.minor added to library name) to match what autotools builds did.
And one more thing, in this setup llvm-config --libs lists static
libraries which is a no-go because Linux distros in the 99% of the
case want to ship only shared libraries.
Same problem with autotools builds. I have a couple of patches that will fix this: http://reviews.llvm.org/D15033 (reverted due to bug, fixed by below)
>> Hi,
>>
>>> 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 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.
>
> And one immediate "problem" shows up. I ended up with
>
> libLLVM-3.9svn.so
>
> and
>
> libclang.so
> libclang.so.3.9
>
> LLVM's shared lib naming looks wrong.
Wrong because they're inconsistent? libLLVM was changed recently
(major.minor added to library name) to match what autotools builds did.
Indeed and doesn't match usual library naming on Linux either. I
believe there was a cmake variable to configure the resulting shared
library name. I'll look it up.
And one more thing, in this setup llvm-config --libs lists static
libraries which is a no-go because Linux distros in the 99% of the
case want to ship only shared libraries.
+1. I use it because it makes a huge difference to build time on incremental debug builds. I generally find that the build time saving is worth a lot more than the run-time cost.