llvm-project
llvm-project copied to clipboard
llvm
LLVM_LINK_LLVM_DYLIB=ON on windows breaks MLIR build
When building LLVM with MLIR enabled and using LLVM_LINK_LLVM_DYLIB=ON, I get a build failure in the linker:
[ 81%] Linking CXX executable ../../../../bin/tblgen-lsp-server.exe
ld.lld: error: duplicate symbol: llvm::inconvertibleErrorCode()
>>> defined at libLLVMSupport.a(Error.cpp.obj)
>>> defined at libLLVM-15.dll
The full command line used is
cmake -G Ninja ../llvm -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PWD/../../lean-llvm -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_USE_LINKER=lld \
-DLLVM_ENABLE_PROJECTS="mlir;llvm;clang;lld;compiler-rt;libcxx;libcxxabi;libunwind" -DLLVM_LINK_LLVM_DYLIB=ON -DLLVM_CCACHE_BUILD=ON\
-DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF -DLLVM_ENABLE_LIBCXX=ON -DLLVM_ENABLE_FFI=OFF\
`# https://boxbase.org/entries/2018/jun/11/minimal-llvm-build/`\
-DLLVM_TARGETS_TO_BUILD='AArch64;WebAssembly;X86'\
`# https://libcxx.llvm.org/BuildingLibcxx.html`\
-DCLANG_DEFAULT_CXX_STDLIB=libc++ -DCLANG_DEFAULT_LINKER=lld -DCLANG_DEFAULT_RTLIB=compiler-rt -DLIBCXX_USE_COMPILER_RT=ON -DLIBCXXABI_USE_COMPILER_RT=ON -DLIBCXXABI_USE_LLVM_UNWINDER=ON -DLIBUNWIND_USE_COMPILER_RT=ON -DCOMPILER_RT_USE_BUILTINS_LIBRARY=ON\
-DCOMPILER_RT_BUILD_SANITIZERS=OFF\
`# hide libc++ symbols in libleanshared`\
-DLIBCXX_HERMETIC_STATIC_LIBRARY=ON -DLIBCXXABI_HERMETIC_STATIC_LIBRARY=ON\
-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON\
-DCMAKE_SYSTEM_IGNORE_PATH=/usr/lib -DLLVM_HOST_TRIPLE=x86_64-w64-windows-gnu -DLLD_DEFAULT_LD_LLD_IS_MINGW=ON \
-DLIBCXX_HAS_WIN32_THREAD_API=ON -DLIBCXXABI_HAS_WIN32_THREAD_API=ON -DLIBCXX_ENABLE_SHARED=OFF
-DLIBCXXABI_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON \
-G "Unix Makefiles"
I just managed to get a virtualbox installed to reproduce and bisect this. AFAIU this never worked, but the issue seems to be limited to tblgen-lsp-server. For some reason, we try to link to libLLVM-15.so despite DISABLE_LLVM_LINK_LLVM_DYLIB being specified. I am confused. I tried various things, but do not know enough of the LLVM build system to see an obvious issue.
The issue I see is similar to the one that has been reported and fixed in https://reviews.llvm.org/D134637.
Build a version of the support library that does not link against libLLVM-.so, to be used by clang-tblgen. This is so clang-tblgen doesn't link against libLLVMSupport twice (once statically and once via libLLVM-.so).
I am surprised I have only seen this issue on Windows.
I am also not sure why TableGen is not part of libLLVM-*.so and why llvm_config (https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/LLVM-Config.cmake#L69) did not automatically create a list of libLLVM + modules that are not part of libLLVM (e.g., TableGen).
I am slowly starting to understand this. Happy to hear advice from somebody who has deeper insights into the LLVM cmake infrastructure.
@nhaehnle @DavidSpickett
I don't know much about this corner of cmake unfortunately.
and fixed in https://reviews.llvm.org/D134637
Just to be sure, do you mean you applied that patch and it fixed your issue? Or that you got the impression that patch had landed? Afaict it is still in review.
If it's the former then that's great, it would be good to leave a comment on that issue saying so.
No, I did not apply it. I feel I would need something similar for MLIR, but this will require some programming that I did not yet find the time to do. I have now everything setup, but run out of time today.
Sorry yes, this was for llvm. I got confused because it came up originally on a bot that builds flang which uses MLIR.
I suspect TableGen is left out of libLLVM-*.so mostly for historical reasons. As the client base of TableGen grows, and it received some refactoring to be friendlier for a wider range of use cases, perhaps it's time to reconsider. Adding TableGen to libLLVM-*.so sounds like it would fix tblgen-lsp-server build issues if you also remove the DISABLE_LLVM_LINK_LLVM_DYLIB. (Which should be fine? At least I don't see an a priori reason why the LSP server must be statically linked when other tools aren't.)
D134637 is a somewhat different case. My understanding is that the *-tblgen tools do have an a priori reason to force static linking: for cross compilation and for LLVM_OPTIMIZED_TABLEGEN builds.
@nhaehnle, you are right! The following patch fixes the issue for me:
diff --git a/llvm/tools/llvm-shlib/CMakeLists.txt b/llvm/tools/llvm-shlib/CMakeLists.txt
index eb4d9891c929..4a6c2b814236 100644
--- a/llvm/tools/llvm-shlib/CMakeLists.txt
+++ b/llvm/tools/llvm-shlib/CMakeLists.txt
@@ -20,7 +20,7 @@ if(LLVM_BUILD_LLVM_DYLIB)
# Exclude libLLVMTableGen for the following reasons:
# - it is only used by internal *-tblgen utilities;
# - it pollutes the global options space.
- list(REMOVE_ITEM LIB_NAMES "LLVMTableGen")
+ # list(REMOVE_ITEM LIB_NAMES "LLVMTableGen")
if(LLVM_DYLIB_EXPORTED_SYMBOL_FILE)
set(LLVM_EXPORTED_SYMBOL_FILE ${LLVM_DYLIB_EXPORTED_SYMBOL_FILE})
diff --git a/mlir/lib/Tools/tblgen-lsp-server/CMakeLists.txt b/mlir/lib/Tools/tblgen-lsp-server/CMakeLists.txt
index 80fc1ffe4029..cb1215d1e94a 100644
--- a/mlir/lib/Tools/tblgen-lsp-server/CMakeLists.txt
+++ b/mlir/lib/Tools/tblgen-lsp-server/CMakeLists.txt
@@ -12,8 +12,6 @@ llvm_add_library(TableGenLspServerLib
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Tools/tblgen-lsp-server
- DISABLE_LLVM_LINK_LLVM_DYLIB
-
LINK_LIBS PUBLIC
MLIRLspServerSupportLib
MLIRSupport
I would gladly submit the patch for review if you believe this is a sensible solution.
Nice. To me this sounds reasonable, after all I suggested it :) I would suggest adding the folks that are on D134637 as well though.
Our bot testing this config on Linux (the issue title here seems to indicate only a Windows issue) is broken after https://reviews.llvm.org/D129116 ; is your patch intended to fix it @tobiasgrosser ?
Please see https://discourse.llvm.org/t/rfc-cleaning-up-how-we-link-tablegen-tools/66678 for an explicit RFC to do what I off-hand proposed here in an earlier comment.
