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

[Wink Saville via Phabricator via llvm-commits]

winksaville added a comment.

In D61804#1499259 <https://reviews.llvm.org/D61804#1499259>, @beanz wrote:

> I question the general utility of this patch, and I don't really think this does anything we want the build system doing.


When you say you don't think the build system should do this, what do you mean?
The llvm_add_library routine without my change already supports generating both,
my change just changes the default cmake entities created from being:

  shared: ${name}
  static: ${name}_static

to:

  shared: ${name}_shared
  static: ${name}



> If you specify `STATIC` and `SHARED` to `llvm_add_library` it creates the shared library target as the one that everything links against, which is exactly what you don't want.

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.

> There are two primary reasons why `BUILD_SHARED_LIBS` is not recommended for non-development builds both have to do with how shared object linking works:
> 
> (1) Is that clang when linked against shared libraries is *way* slower (I think last I measured was over 10%). This is caused by the need for resolving linkage at process launch every time a process is launched.
> 
> (2) Is that LLVM relies on a strange mess of static initializers used for static registration. The most problematic one is cl::opt. When you link a static archive only the object files that contain unresolved symbols get pulled in, when you link against a shared object, all of it gets pulled in. Because static archives selectively pull in object files (and their static initializers) we have had issues in the past where the static build of LLVM works, but the shared build produces runtime errors from cl::opt.
> 
> I'm curious to understand the problem you are trying to solve. From other posts on the list it really sounds to me like you want a variant of libClang that exports the entire Clang API surface rather than just the C API. I think there are better ways to accomplish that.

The problem is that some people want to use shared libraries and some want static. In particular Arch Linux prefers shared over static and with clang there is no option for building both so they end up building only shared. I'm trying to allow both to be built and ask the Arch Linux people to distribute both.

> Exposing Clang's libraries for piecemeal consumption is a much bigger problem than just the build system not building libClang*.so. For example, Clang has no equivalent of llvm-config, so there is no external representation of the clang dependency graph that users can rely on.
> 
> This all aside, I also have issues with this implementation described inline below.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61804