| Summary: | sys-devel/clang: undefined symbol: LLVMInitializeNVPTXTargetInfo (at runtime if llvm dropped it) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Erik Quaeghebeur <gentoo> |
| Component: | Current packages | Assignee: | LLVM support project <llvm> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | herrtimson, ionen, mgorny |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=767700 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Erik Quaeghebeur
2021-02-01 20:41:15 UTC
(I wanted to attach the build log, but Bugzilla errors out when I try that.) Is this a duplicate of bug 767700? (In reply to Emily Rowlands from comment #2) > Is this a duplicate of bug 767700? Close, but there's a difference with lld in that it doesn't define LLVM_TARGETS yet still needs a rebuild. Given there's no mechanism (in current eapi) to force rebuilds on USE-based ABI changes you do preferably need to update everything that use LLVM_TARGETS together using --changed-use or similar. (In reply to Ionen Wolkens from comment #3) > (In reply to Emily Rowlands from comment #2) > > Is this a duplicate of bug 767700? > Close, but there's a difference with lld in that it doesn't define > LLVM_TARGETS yet still needs a rebuild. What do I need to rebuild? (I tried lld, but that does not fix it.) (In reply to Erik Quaeghebeur from comment #4) > What do I need to rebuild? (I tried lld, but that does not fix it.) I think clang, I'm testing myself to find more proper steps to reproduce. My guess is that something along those lines happened: 1. have clang and llvm with NVPTX 2. rebuilt clang without NVPTX first (llvm still has it, causing clang to use the symbol) 3. rebuilt llvm without NVPTX (symbol is gone) (In reply to Ionen Wolkens from comment #5) > My guess is that something along those lines happened: > 1. have clang and llvm with NVPTX > 2. rebuilt clang without NVPTX first (llvm still has it, causing clang to > use the symbol) > 3. rebuilt llvm without NVPTX (symbol is gone) Can confirm this successfully breaks clang like what you're getting. $ clang -o hello hello.c clang: symbol lookup error: clang: undefined symbol: LLVMInitializeNVPTXTargetInfo, version LLVM_11 Similarly to lld, rebuilding clang will fix this (thankfully gcc is default, as rebuilding clang with clang wouldn't work here). This has nothing to do with firefox so I'll tentatively assign to clang (but it's more of a generalized issue). (In reply to Ionen Wolkens from comment #5) > (In reply to Erik Quaeghebeur from comment #4) > > What do I need to rebuild? (I tried lld, but that does not fix it.) > I think clang, […] I can confirm as well. I can emerge Firefox again after remerging clang. Did you have sys-devel/clang built with NVPTX backend before? Did Portage somehow allow you to rebuild sys-devel/llvm without it while breaking clang's dependency graph or is that a case of automagic dep? (In reply to Michał Górny from comment #8) > Did you have sys-devel/clang built with NVPTX backend before? Yes, I think so. > Did Portage somehow allow you to rebuild sys-devel/llvm without it while > breaking clang's dependency graph or is that a case of automagic dep? I just put -NVPTX and emerged -U both. So I guess they were remerged in the wrong order? It's kind of automagic I guess. Building clang[-nvptx] against llvm[nvptx] does not break deps (the other way around would). And despite -nvptx, clang will still use the nvptx symbols if llvm has them. At this point nothing stops you from rebuilding llvm without nvptx and losing the symbols. The same happens with lld despite it doesn't even use LLVM_TARGETS. Well, more like ABI breakage than automagic I guess. See the see also bug #767700 if haven't yet, had more logs/details, and lld is quicker to test than clang. the LLVM_TARGETS flags for clang don't work. clang will always be built with references to all llvm symbols for all targets even if those use flags are not set in clang. thus clang gets stuck in the following state if you remove some flags from llvm and clang: clang: symbol lookup error: clang: undefined symbol: LLVMInitializeVETargetInfo, version LLVM_12 ---- symbols in clang after rebuild, even with the use flags for those targets unset: $ strings /usr/lib/llvm/12/bin/clang-12 | grep -e 'LLVMInitialize.*TargetInfo' | sort LLVMInitializeAArch64TargetInfo LLVMInitializeAMDGPUTargetInfo LLVMInitializeARCTargetInfo LLVMInitializeARMTargetInfo LLVMInitializeAVRTargetInfo LLVMInitializeBPFTargetInfo LLVMInitializeCSKYTargetInfo LLVMInitializeHexagonTargetInfo LLVMInitializeLanaiTargetInfo LLVMInitializeMipsTargetInfo LLVMInitializeMSP430TargetInfo LLVMInitializeNVPTXTargetInfo LLVMInitializePowerPCTargetInfo LLVMInitializeRISCVTargetInfo LLVMInitializeSparcTargetInfo LLVMInitializeSystemZTargetInfo LLVMInitializeVETargetInfo LLVMInitializeWebAssemblyTargetInfo LLVMInitializeX86TargetInfo LLVMInitializeXCoreTargetInfo ---- llvm target flags set during rebuild: $ equery u sys-devel/clang | grep targets +llvm_targets_AArch64 -llvm_targets_AMDGPU +llvm_targets_ARM +llvm_targets_AVR +llvm_targets_BPF -llvm_targets_Hexagon -llvm_targets_Lanai -llvm_targets_MSP430 -llvm_targets_Mips -llvm_targets_NVPTX +llvm_targets_RISCV -llvm_targets_Sparc +llvm_targets_SystemZ +llvm_targets_WebAssembly +llvm_targets_X86 -llvm_targets_XCore The problem was probably not caused by the following commit, but the commit made my llvm and clang have to be rebuilt with fewer targets. Thus it seems to have made the problem more obvious. https://gitweb.gentoo.org/repo/gentoo.git/commit/profiles?id=0efcbad3f9f152df49eb8307f5cb7112ee22595e I can see in my emerge output that the cmake command has the targets flag with the correct subset of LLVM_TARGETS that I specified, rather than the larger set of all targets: -DLLVM_TARGETS_TO_BUILD=AVR;RISCV;PowerPC;WebAssembly;SystemZ;BPF;ARM;X86;AArch64 And yet, the clang binary is linked against all the targets in the lib/Basic/Targets directory, including ones that it does not need: # ls /var/tmp/portage/sys-devel/clang-12.0.1/work/clang/lib/Basic/Targets AArch64.cpp ARM.h Lanai.cpp MSP430.h PPC.cpp SPIR.h WebAssembly.cpp AArch64.h AVR.cpp Lanai.h NVPTX.cpp PPC.h SystemZ.cpp WebAssembly.h AMDGPU.cpp AVR.h Le64.cpp NVPTX.h RISCV.cpp SystemZ.h X86.cpp AMDGPU.h BPF.cpp Le64.h OSTargets.cpp RISCV.h TCE.cpp X86.h ARC.cpp BPF.h Mips.cpp OSTargets.h Sparc.cpp TCE.h XCore.cpp ARC.h Hexagon.cpp Mips.h PNaCl.cpp Sparc.h VE.cpp XCore.h ARM.cpp Hexagon.h MSP430.cpp PNaCl.h SPIR.cpp VE.h This results in the clang undefined symbol error (see previous comment) unless I always build llvm with LLVM_TARGETS='*', which I no longer want to do. I was getting this problem with the thunderbird rebuild after changing the LLVM_TARGETS to not include the NVPTX target. I was able to resolve it by rebuilding the linker package - "sys-devel/lld". It seems that it doesn't depend on LLVM_TARGETS and it seems the reverse dependency code in portage didn't detect that it needs to be rebuilt after this change to LLVM_TARGETS. |
