Hi!
When including the llvm/ADT/DenseMap.h
header in omptarget.h
, the linking fails and errors out:
undefined reference to symbol ‘_ZN4llvm23EnableABIBreakingChecksE’.
I already verified that it picks up the right headers.
Any idea of what the problem could be?
So, there’s the Config/abi-breaking.h
header that’s being imported by one of the support headers. This has an external reference to said variable which should be defined by ABIBreak.cpp
in Support
. But we already link in Support
so it should be there. Those variables are controlled by LLVM_ENABLE_ABI_BREAKING_CHECKS
. So it’s possible that it’s picking up a library that has it disabled while trying to use a header that has it enabled?
Thanks @jhuber6 for your reply. How do I verify which library is picking up?
Are you building with -DBUILD_SHARED_LIBS=ON
? Otherwise it should pick up the internal libraries statically.
Yes I am. This is my build command:
cmake ../llvm \
-DCMAKE_BUILD_TYPE=Release -G Ninja \
-DCMAKE_INSTALL_PREFIX='../../../soft/gpu_a100/llvm_main/' \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
-DLLVM_ENABLE_RUNTIMES='openmp' \
-DLLVM_ENABLE_PROJECTS='clang;compiler-rt' \
-DLLVM_ENABLE_BACKTRACES=ON \
-DLLVM_APPEND_VC_REV=OFF \
-DLLVM_ENABLE_ASSERTIONS=ON \
-DBUILD_SHARED_LIBS=ON \
-DLLVM_OPTIMIZED_TABLEGEN=ON \
-DLLVM_CCACHE_BUILD=OFF \
-DCLANG_ENABLE_STATIC_ANALYZER=ON \
-DLIBOMPTARGET_NVPTX_COMPUTE_CAPABILITIES=60,70,80 \
-DOPENMP_ENABLE_LIBOMPTARGET=ON \
-DLIBOMPTARGET_NVPTX_ENABLE_BCLIB=true \
-DLIBOMPTARGET_NVPTX_DEBUG=ON \
-DLIBOMPTARGET_ENABLE_DEBUG=ON \
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON
Can you find an executable that built and run ldd
on it? E.g. ldd ./bin/llc | grep 'libLLVMSupport.so'
.
FWIW, these options shouldn’t be necessary. I removed LIBOMPTARGET_NVPTX_COMPUTE_CAPABILITIES
recently, it’s replaced with LIBOMPTARGET_DEVICE_ARCHITECTURES=<list>|all|auto
. So you would use sm_60;sm_70;sm_80
to be equivalent. Or use auto
to have it detect your system’s architecture. Or leave it at the default all
and support every architecture at the expense of a second or two of build time.
-DLIBOMPTARGET_NVPTX_COMPUTE_CAPABILITIES=60,70,80 \
-DOPENMP_ENABLE_LIBOMPTARGET=ON \
-DLIBOMPTARGET_NVPTX_ENABLE_BCLIB=true \
-DLIBOMPTARGET_NVPTX_DEBUG=ON \
Yes, this is the output:
ldd ./bin/llc | grep 'libLLVMSupport.so'
libLLVMSupport.so.17git => ./OpenMP_Offloading/llvm-project/build_main/./bin/../lib/libLLVMSupport.so.17git (0x00007fcdaba1a000
Is that the expected library you want to bind to the build? It seems different from your desired install prefix. Search the symbols in that library to see what it actually has, e.g.
$ llvm-nm /OpenMP_Offloading/llvm-project/build_main/./bin/../lib/libLLVMSupport.so.17git | grep 'ABIBreaking'
Since I haven’t yet run ‘ninja install’ the desired install folder is empty. So I believe that is the library to which I want to bind my build. But I’m not sure, and I could be wrong…
In any case, the missing symbol is in the shared library.
llvm-nm ./OpenMP_Offloading/llvm-project/build_main/./bin/../lib/libLLVMSupport.so.17git | grep 'ABIBreaking'
0000000000636c04 B _ZN4llvm23EnableABIBreakingChecksE
That’s surprising, I’m wondering which library it’s trying to pull in at build time then. The easy solution here is to not use the shared library option. My guess is there’s a library that’s being pulled in during link time that has the option set differently? I don’t know if there’s multiple libraries on your system and maybe one of them doesn’t contain that symbol.
What if it’s picking up libraries from the llvm project I installed before (which isn’t the one I’m building)? I can try to rebuild llvm and use the resulting clang
Starting with a clean build might help. And double checking to make sure that the current LLVM you’re building as the ABI breaking checks on. What’s the motivation to use the shared library option? It’s mostly helpful for developers as it reduces build time and binary size, but for users it’s usually best to statically link the binaries so it’s easier to distribute.
1 Like