Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
clang-tblgen build: avoid duplicate inclusion of libLLVMSupport
TableGen executables are supposed to never be linked against libLLVM-*.so, even when LLVM_LINK_LLVM_DYLIB=ON, presumably for cross-compilation. It turns out that clang-tblgen *did* link against libLLVM-*.so, indirectly so via the clangSupport. This lead to a regression in what should have been unrelated work of cleaning up ManagedStatics in LLVMSupport. A running clang-tblgen process ended up with two copies of a cl::opt static global: - one from libLLVMSupport linked statically into clang-tblgen as a direct dependency - one from libLLVMSupport linked into libLLVM-*.so, which clang-tblgen linked against due to the clangSupport dependency For a bit more context, see the discussion at https://discourse.llvm.org/t/flang-aarch64-dylib-buildbot-need-help-understanding-a-regression-in-clang-tblgen/64871/ None of the potential solutions I could find are perfect. Presumably one possible solution would be to remove "Support" from the explicit dependencies of clang-tblgen. However, relying on the transitive inclusion via clangSupport seems risky, and in any case this wouldn't address the issue of clang-tblgen surprisingly linking against libLLVM-*.so. This change instead creates a second version of the clangSupport library that is explicitly linked statically, to be used by clang-tblgen. v2: - define an alias so that clang-tblgen can always link against "clangSupport_tablegen" - use add_llvm_library(... BUILDTREE_ONLY ...) v3: - use the object library version of clangSupport if available Differential Revision: https://reviews.llvm.org/D134637
- Loading branch information