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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
