[PATCH] D61909: Add Clang shared library with C++ exports

[Chris Bieneman via Phabricator via cfe-commits]

beanz added a comment.

In D61909#1510955 <https://reviews.llvm.org/D61909#1510955>, @E5ten wrote:

> @beanz Well I took libclang_shared as effectively an equivalent to the libLLVM.so that's created with that dylib option, and when BUILD_SHARED_LIBS is enabled that library is not created, in fact the option to create that library conflicts with BUILD_SHARED_LIBS.


That conflict is because of how I implemented libLLVM, and is something I'm looking to change. I'm hoping to put up a patch this week that will update how we generate libLLVM to be more like how libclang_shared is built.

> Also when the libs are built shared and also as object libraries that are linked into libclang_shared would that not cause the same libraries to be linked into executables twice, once through the shared libraries and once through libclang_shared?

Object libraries are just collections of object files without linkage dependencies. The whole point of implementing libclang_shared in terms of object files is to allow constructing libclang_shared even if `BUILD_SHARED_LIBS` is enabled, and without using extra linker flags to force the linker to treat all the clang static archives as collections of object files (we do that in libLLVM using --all_load and --whole-archive flags).

It shouldn't result in duplicating the linkage because libclang contains all the code and shouldn't have any external resolutions against the libclang* component libraries.

One big reason that I don't want to disable generating libclang_shared (or libLLVM) if `BUILD_SHARED_LIBS=On` is because libclang_shared is intended to be a shippable binary unlike the `BUILD_SHARED_LIBS` libraries, so it really should be enabled in every possible build configuration that we can make it work.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61909