Building SVN head with CMake - shared libraries?

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 the end I got the following shared libraries:

/tools/llvm/svn_head/lib/BugpointPasses.so
/tools/llvm/svn_head/lib/libclang.so
/tools/llvm/svn_head/lib/libclang.so.3.9
/tools/llvm/svn_head/lib/liblldb.so
/tools/llvm/svn_head/lib/liblldb.so.3.9.0
/tools/llvm/svn_head/lib/libLTO.so
/tools/llvm/svn_head/lib/LLVMHello.so

However, with an autoconf build, I am used to seeing a libLLVM.so. From a 3.7.1 autoconf build:

/tools/llvm/3.7.1dbg/lib/BugpointPasses.so
/tools/llvm/3.7.1dbg/lib/libclang.so
/tools/llvm/3.7.1dbg/lib/liblldb.so
/tools/llvm/3.7.1dbg/lib/libLLVM-3.7.1.so
/tools/llvm/3.7.1dbg/lib/libLLVM-3.7.so
/tools/llvm/3.7.1dbg/lib/libLTO.so
/tools/llvm/3.7.1dbg/lib/LLVMHello.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?

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 the end I got the following shared libraries:

/tools/llvm/svn_head/lib/BugpointPasses.so
/tools/llvm/svn_head/lib/libclang.so
/tools/llvm/svn_head/lib/libclang.so.3.9
/tools/llvm/svn_head/lib/liblldb.so
/tools/llvm/svn_head/lib/liblldb.so.3.9.0
/tools/llvm/svn_head/lib/libLTO.so
/tools/llvm/svn_head/lib/LLVMHello.so

However, with an autoconf build, I am used to seeing a libLLVM.so. From a 3.7.1 autoconf build:

/tools/llvm/3.7.1dbg/lib/BugpointPasses.so
/tools/llvm/3.7.1dbg/lib/libclang.so
/tools/llvm/3.7.1dbg/lib/liblldb.so
/tools/llvm/3.7.1dbg/lib/libLLVM-3.7.1.so
/tools/llvm/3.7.1dbg/lib/libLLVM-3.7.so
/tools/llvm/3.7.1dbg/lib/libLTO.so
/tools/llvm/3.7.1dbg/lib/LLVMHello.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.

HTH,
Andrew

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.

We should probably be updating [1] too given that this document talks
exclusively about compiling with the Autoconf/Makefile build system.

@Hans @Chris:

Should the packaging instructions refer to the CMake or
Autoconf/Makefile build system for the LLVM 3.8 release?

[1] http://llvm.org/docs/Packaging.html

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

@Hans @Chris:

Should the packaging instructions refer to the CMake or
Autoconf/Makefile build system for the LLVM 3.8 release?

Maybe, I’ll defer that to Hans. I believe the packaging scripts are on CMake, so we’ve at least gotten that far.

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.

@Hans @Chris:

Should the packaging instructions refer to the CMake or
Autoconf/Makefile build system for the LLVM 3.8 release?

Maybe, I’ll defer that to Hans. I believe the packaging scripts are on CMake, so we’ve at least gotten that far.

I wasn't even aware of [1] until now. The release packaging script is
using CMake since 3.7.

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

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

-Chris

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.

Thanks!

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.

Joerg

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, 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?

Yes.

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

-Chris

Thanks - I’ll try this tonight.

Assuming it works, should these variables be added to the docs at http://llvm.org/docs/CMake.html ?

http://reviews.llvm.org/D16208

Cheers,
Andrew

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

Hi,

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.

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.

Regards,
ismail

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.

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)

http://reviews.llvm.org/D15986

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

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)
   http://reviews.llvm.org/D15986

I'll have a look, thanks!

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