[PATCH] D61804: Support building shared and static libraries simultaneously

Mon May 13 08:50:10 PDT 2019

beanz added a comment.

In D61804#1499275 <https://reviews.llvm.org/D61804#1499275>, @winksaville wrote:

> When you say you don't think the build system should do this, what do you mean?

`llvm_add_library` supports both, because there are places where we consciously choose to build both. That's not the problem. What I don't think the build system should do, is take an unsupported distribution format (which is unsupported for technical reasons), and make it supported without resolving the technical issues.

> With the change I've made when both are specified the default cmake entity, ${name}, is the static libraries. When neither are specified the default is static or shared depending on BUILD_SHARED_LIBS which is unchanged.

I missed that you were renaming the targets before calling `llvm_add_library` so that isn't an issue, but there are still lots of issues here. Like, if you specify your new option to generate clang static libraries but don't specify `BUILD_SHARED_LIBS` or `LLVM_USE_LLVM_DYLIB` each of your clang libraries will get statically linked against its own copy of LLVM, which not only makes your libraries big, it also makes them not work. You can't link more than one copy of LLVM into a single process memory space safely because of LLVM's use of global data.

> The problem is that some people want to use shared libraries and some want static.

Why? I generally think most people don't understand the trade-offs, and I'm not sure we should feed into that.

> I'm trying to allow both to be built and ask the Arch Linux people to distribute both.

Arch Linux is in an unsupported state, and your patch isn't the way forward.

Let's rewind.

Why do "some people like shared libraries"? There are usually two reasons people cite for linking shared libraries. One is reduced binary distribution size because you're reducing duplication of code. The other, is the ability to update libraries without updating tools.

The later, is not an issue here. LLVM and Clang's C++ libraries don't provide any API or ABI stability guarantees across releases, so there is no way you're going to reasonably update LLVM or Clang libraries without rebuilding the applications using them.

The former can be valuable, but it comes at a cost. Dynamic resolution of symbols slows down process launch time, and dynamic resolution of C++ link-once ODRs are exceptionally slow. If you are building a compiler, chances are you don't want to slow down your process launch that much. But let's pretend you don't care. Your solution still isn't the right way to do this.

Creating component shared libraries results in duplicating all the C++ link-once ODRs across each shared module. That will not only slow down your process launch, but bloat the size of your binary distribution.

In D61804#1499276 <https://reviews.llvm.org/D61804#1499276>, @winksaville wrote:

> It looks to me that llvm, libunwind and libcxx support building both, so the goal isn't unprecedented,

This is very much an apple and oranges comparison. For one, LLVM does not support generating component dylibs and shared libs. It supports generating libLLVM, a single dylib containing all of the LLVM components rolled together. libunwind, libcxx, libcxxabi, are runtime libraries that are designed to allow static linkage, and they don't link LLVM.

I apologize that I missed your thread on the dev list, because that would have been a much better place to have this conversation. Having gone back and read it now, it sounds to me like what you really want is a clang equivalent of libLLVM. That is a reasonable and viable thing to want. This patch (https://reviews.llvm.org/P8147) is a first stab. I'm happy to prepare that for landing in Clang if that meets your needs, and that is a viable way forward.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61804/new/

https://reviews.llvm.org/D61804