[PATCH] D63881: [cmake] Fix build with BUILD_SHARED_LIBS=ON

[Chris Bieneman via Phabricator via llvm-commits]

beanz added a comment.

Reading through the old comments on this thread I think there are a few things going on here, but the core of the issue is you're using `BUILD_SHARED_LIBS` *outside* LLVM's build system. That is explicitly not supported (https://www.llvm.org/docs/CMake.html). We do not support `BUILD_SHARED_LIBS` for distributing LLVM in any form.

In D63881#1561325 <https://reviews.llvm.org/D63881#1561325>, @cristian.adam wrote:

> TestPlugin depends on Core.  Core depends on BinaryFormat, Remarks, and Support. If we keep `PRIVATE` then TestPlugin will also need the dependencies from Core.


For legacy reasons, we actually have a different system for how we manage transitive library dependencies for the shared library build (llvm-config & LLVMBuild). Making this change would result in over-specifying the dependency graph inside the LLVM build tree, which could have adverse impact on our development build times, and the `BUILD_SHARED_LIBS` option exists solely to speed up slow builds. Seems counter-productive.

> At the moment LLVM/Clang has no dependencies in the CMake exports when `BUILD_SHARED_LIBS` is set to `ON`.
> 
> While building Qt Creator we had to add all the little libraries that `libclang` or `libTooling` depends because on Linux LLVM is being built with `BUILD_SHARED_LIBS=ON` :(

If you insist on building this way, which you shouldn't, you will need to use llvm-config to get the transitive library dependencies setup correctly, the CMake exports will not work.

Additionally the change you are making to `TestPlugin` will almost certainly break some of our more common configurations (`BUILD_SHARED_LIBS=Off` comes to mind). The problem is that LLVM can't have more than one copy of itself in the same process memory space because it relies on global data in silly ways.

If you build your patch with `BUILD_SHARED_LIBS=Off` (the default configuration), this should result in LLVMSupport being linked into the `TestPlugin` library as well as into the `PluginTests` tool that eventually loads it. When the test runs and it loads the TestPlugin... kaboom (llvm should hit an assert).

We should add `PLUGIN_TOOL PluginTest` to the `add_llvm_library` call for `TestPlugin`, which will tell TestPlugin to link against PluginTest's LLVM. That will fix some build configurations (and not break any others), but may not resolve this particular issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63881