MaskRay added a comment. In D75579#1912535 <https://reviews.llvm.org/D75579#1912535>, @serge-sans-paille wrote:
> @MaskRay The library version prooved to be a bad path: we wanted clang-cpp to > always link to a shared library, which interacts in ungraceful ways with > BUILD_SHARED_LIBS. > > This is another attempt that looks better to me: all options are available in > LLVMCodeGen, but only registered if a given static constructor is called by > client code. Some doc and asserts are missing but that's the rough idea. Any > thoughts? I think the patch is moving toward the correct direction and fixes some problems, so there is still value to land it. Placing static constructors in a header which may be included in two places in an application (application codegen; lld depended by the application) is bad. With this patch, at least the `-DBUILD_SHARED_LIBS=off` build (`libLLVM*.a`) will work now. (A `-DBUILD_SHARED_LIBS=on` build will also work. In this case, the application should link against `libLLVM*.so` and `libclang*.so`, but no distribution has done this. The application will have to link against a number of `libclang*.so`, instead of a single `libclang-cpp.so`) A copy of `libLLVMCoreGen.a` is linked into `libclang-cpp.so`. If the application depends on `libclang-cpp.so`, it cannot pull in another `libLLVMCodeGen.a`, because that will cause duplicate registration of `llvm::cl::opt` flags. I agree that we have to let client code explicitly initialize (register) the flags. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75579/new/ https://reviews.llvm.org/D75579 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
