Summary: | sys-devel/lld: needs rebuild if LLVM_TARGETS on llvm changed. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Kenzelmann <gentoo> |
Component: | Current packages | Assignee: | LLVM support project <llvm> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | 1i5t5.duncan, chiitoo, dan, egger.m, fordfrog, gentoo-bugzilla, hjckr, hougelangley1987, ionen, matthew, mgorny, mr.oneacer, pacho, sam, simon.vanderveldt+gentoo, srcshelton |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=768267 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
Source of shared lib I used |
Description
Daniel Kenzelmann
2021-01-27 20:46:09 UTC
I have NVPTX disabled with (X86) being the only LLVM_TARGET and 85.0 built fine for me. Could you attach the full log? There may be more going on here. But from what I see, it feels like your clang toolchain is broken. Created attachment 684942 [details]
build.log
Can you please show: $ emerge -pv --nodeps llvm rust clang # emerge -pv --nodeps llvm rust clang These are the packages that would be merged, in order: [ebuild R ] sys-devel/llvm-11.0.1:11::gentoo USE="libffi ncurses xml -debug -doc -exegesis -gold -libedit -test -xar -z3" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="BPF (X86) -AArch64 -AMDGPU (-ARC) -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ (-VE) -WebAssembly -XCore" 0 KiB [ebuild R ] dev-lang/rust-1.48.0:stable/1.48::gentoo USE="-clippy -debug (-doc) -libressl (-miri) -nightly -parallel-compiler -rls -rustfmt -system-bootstrap -system-llvm -test -wasm" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_TARGETS="BPF (X86) -AArch64 -AMDGPU -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 0 KiB [ebuild R ] sys-devel/clang-11.0.1:11::gentoo USE="static-analyzer xml -debug -default-compiler-rt -default-libcxx -default-lld -doc -test" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="BPF (X86) -AArch64 -AMDGPU (-ARC) -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ (-VE) -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_8 -python3_7 -python3_9" 0 KiB Total: 3 packages (3 reinstalls), Size of downloads: 0 KiB Can you try to rebuild lld? I'd like to think that it doesn't need to be rebuilt on target changes, but it's the impression I'm getting here. emerge -1 sys-devel/lld That seemed to do the trick, firefox is compiling now :) Thanks! Glad to hear :) Tried to reproduce meanwhile, and sure enough: $ strings /usr/bin/ld.lld | grep 'LLVMInitialize.*TargetInfo' LLVMInitializeNVPTXTargetInfo LLVMInitializeX86TargetInfo After rebuilding llvm without NVPTX: $ clang -fuse-ld=lld -o hello hello.c /usr/bin/ld.lld: symbol lookup error: /usr/bin/ld.lld: undefined symbol: LLVMInitializeNVPTXTargetInfo, version LLVM_11 clang-11: error: unable to execute command: No such file or directory clang-11: error: linker command failed due to signal (use -v to see invocation) My personal opinion, to avoid failure on a system which defaults to lld and would have trouble rebuilding lld with lld, would be that sys-devel/lld shouldn't be a separate package. Unless there's some other way to deal with this. *** Bug 768900 has been marked as a duplicate of this bug. *** Maybe we should add LLVM_TARGETS to lld? Then lld would be rebuilt. And nobody should change LLVM_TARGETS for sys-devel/llvm only. (In reply to jospezial from comment #10) > Maybe we should add LLVM_TARGETS to lld? > Then lld would be rebuilt. > And nobody should change LLVM_TARGETS for sys-devel/llvm only. While it would reduce issues, I find it unfortunate this would lock out of rebuilding lld with lld, e.g. have to link with ld.bfd/gold given ld.lld is broken. Optimally it would be nice if clang/lld were never in a broken state because another component changed, much like wouldn't want that to happen to gcc/binutils. (In reply to Ionen Wolkens from comment #11) > Optimally it would be nice if clang/lld were never in a broken state because > another component changed. And if abi issues can't be avoided and rebuilds are necessary, the only real solution I see to this is for llvm to not be a split package. But some simpler solution to ensure lld is rebuilt meanwhile wouldn't hurt. I've added new arches to LLVM_TARGETS and removed BPF from there and then tried to recompile 'clang'. Once llvm got updated and had BPF removed, clang would no longer compile. I've tried to recompile the linker lld, but no luck there either. I've tried to recompile clang/lld with gcc, but this was not successful either. How is one supposed to be able to remove 'BPF' from existing clang/llvm install? llvm-12.0.1 clang-12.0.1 lld-12.0.1 I had to deploy a binary package of llvm that had +BPF target to be able to restore the toolchain. In the end, I've added the new arches to the targets leaving BPF in the list: $ emerge -pv --nodeps clang rust llvm These are the packages that would be merged, in order: [ebuild R ] sys-devel/clang-12.0.1:12::gentoo USE="default-compiler-rt default-libcxx default-lld llvm-libunwind static-analyzer -debug -doc -test -xml" LLVM_TARGETS="AArch64* ARM* BPF (X86) -AMDGPU -ARC -AVR (-CSKY) -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -VE -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_9 (-python3_10) -python3_8" 0 KiB [ebuild N ] dev-lang/rust-1.53.0:stable/1.53::gentoo USE="-clippy -debug -doc (-miri) (-nightly) (-parallel-compiler) -rls -rustfmt (-system-bootstrap) (-system-llvm) -test -verify-sig -wasm" CPU_FLAGS_X86="sse2" LLVM_TARGETS="AArch64 ARM BPF (X86) -AMDGPU -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 252676 KiB [ebuild R ] sys-devel/llvm-12.0.1:12::gentoo USE="libffi ncurses -debug -doc -exegesis -gold -libedit -test -xar -xml -z3" LLVM_TARGETS="AArch64* ARM* BPF (X86) -AMDGPU -ARC -AVR (-CSKY) -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -VE -WebAssembly -XCore" 0 KiB I have the same question as the previous comment, and more information to add. I previously had LLVM_TARGETS='*', but the VE and ARC targets were recently masked on my arch (ppc64). So llvm was rebuilt first, and then clang. The /usr/lib/llvm/12/lib64/libLLVM-12.so object was rebuilt without symbols like LLVMInitializeVETargetInfo, but clang still had references to these: $ strings /usr/lib/llvm/12/bin/clang | grep LLVMInitializeVETargetInfo LLVMInitializeVETargetInfo So when clang runs during the clang rebuild, it is broken: clang: symbol lookup error: clang: undefined symbol: LLVMInitializeVETargetInfo, version LLVM_12 ---- I restored the LLVM_TARGETS and rebuilt llvm, but clang still has the references to the old symbols: [ebuild R ] sys-devel/clang-12.0.1:12::gentoo USE="static-analyzer -debug -default-compiler-rt (-default-libcxx) -default-lld -doc -llvm-libunwind -test -xml" LLVM_TARGETS="AArch64 ARM AVR BPF (PowerPC) RISCV SystemZ WebAssembly X86 -AMDGPU (-ARC) (-CSKY) -Hexagon -Lanai -MSP430 -Mips -NVPTX -Sparc (-VE) -XCore" PYTHON_SINGLE_TARGET="python3_9 (-python3_10) -python3_8" 0 KiB $ strings /usr/lib/llvm/12/bin/clang | grep LLVMInitializeVETargetInfo LLVMInitializeVETargetInfo ---- How do I rebuild clang to remove these symbols? in my case, i put LLVM_TARGETS="NVPTX" in /etc/portage/make.conf and since then i was not able to compile (configure) firefox nor thunderbird, it ended up with this error: 0:02.10 checking for linker... 0:02.10 DEBUG: Executing: `/usr/lib/llvm/12/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -fuse-ld=lld -Wl,--version` 0:02.10 ERROR: Could not use lld as linker after re-emerging lld the configuration does not fail anymore. tested on two machines with nvidia gpu. I've tried addressing this a few times and couldn't figure out a good way to make lld (or even clang, tbh) respect LLVM_TARGETS fully without copying the initializers from LLVM itself. To be honest, at this point I'm considering use.forcing all (non-masked) targets for the time being. While this is far from a perfect solution and has an inevitable cost in build time, it should at least prevent non-expert users from breaking their systems and give a fair warning to expert users. *** Bug 821436 has been marked as a duplicate of this bug. *** Created attachment 764063 [details]
Source of shared lib I used
clang and rust also have this problem. I wanted to remove the extra ARM targets I had on llvm (only, not clang/rust) on a amd64 system, so I rebuild llvm without it. Then, clang and rust would complain about missing initialization symbols for ARM. For rust, it's especially tricky if one wants to use system-bootstrap, as it needs a working rust.
I solved this by reinstalling rust with LD_PRELOAD set to a small shared library containing the missing symbols (I'm attaching the source). It's ugly, but allowed reinstalling rust keeping system-bootstrap.
Could a solution be to always define the missing symbols, which would do nothing if the target isn't there?
Maybe a news item when use.forcing a bunch of exotic stuff like that next time? It's not like we all have that $10K+ threadripper I've been begging Santa for after all.[1] I ended up profile/use.mask-ing everything I didn't need and have set already for the older versions (with a comment referencing this bug) as the llvm-13.0.1 update was taking /forever/ building exotic targets like sparc and hexagon that I haven't even the /slightest/ interest in. --- [1] Maybe after the car is paid off later this year I can /think/ about upgrading my decade-old 6-core fx6100 bulldozer-1 hardware... still unlikely to the $10k+ 64-core/128-thread threadripper w/ 256G RAM for all those threads to play, but one can dream... (In reply to Duncan from comment #19) > Maybe a news item when use.forcing a bunch of exotic stuff like that next > time? It's not like we all have that $10K+ threadripper I've been begging > Santa for after all.[1] > > I ended up profile/use.mask-ing everything I didn't need and have set > already for the older versions (with a comment referencing this bug) as the > llvm-13.0.1 update was taking /forever/ building exotic targets like sparc > and hexagon that I haven't even the /slightest/ interest in. Please do try leave the snark out of it. As you can see in this bug, it's not really (sadly) about whether people are interested in random targets, but about how fragile Rust and other consumers are (like LLD) when the targets are changed at all, and in fact, surprisingly, some things like Zig *need* all targets on. We tend to prefer news items when there's something actionable and in this case, for most people, they _shouldn't_ do anything for the aforementioned reasons. But yes, maybe it would've been useful for informative purposes. (In reply to Duncan from comment #19) ...snip... > I ended up profile/use.mask-ing everything I didn't need and have set > already for the older versions (with a comment referencing this bug) as the > llvm-13.0.1 update was taking /forever/ building exotic targets like sparc > and hexagon that I haven't even the /slightest/ interest in. ...snip... I have ended up doing the same thing when I noticed all these arches will get compiled in with the upgrade to clang/llvm version 13.0.1. And I do not understand why this so is. Why did portage suddenly stop respecting LLVM_TARGETS from make.conf and bundled it all together? This is not a one size fits all distribution... (In reply to Nikolay Kichukov from comment #21) > And I do not understand why this so is. Why did portage suddenly stop > respecting LLVM_TARGETS from make.conf and bundled it all together? That's the power of use.force at the profile level, tho it's normally used far more "surgically" than this, with the contrast to normal what makes this so shocking. That said... > This is not a one size fits all distribution... It's supposed to be a temporary fix. I understand (at a high level) why they did it and could imagine myself taking a similar approach to the problem while working on something better, but a warning (such as the news item I suggested) would have been appreciated, precisely for the reason you mentioned -- this is /not/ (normally) a one-size-fits-all distro. Luckily for us, by the same token, gentoo policy is to always provide user overrides for such things, with the result being gentoo's flexibility and ability to do and be used for all sorts of things normal distros can't, at least without far more invasive tweaking. I'm fine with us having a pkg_postinst comparison with saved LLVM_TARGETS in pkg_preinst and warning if they differ. (In reply to Sam James from comment #23) > I'm fine with us having a pkg_postinst comparison with saved LLVM_TARGETS in > pkg_preinst and warning if they differ. (I don't have time to do this today or any time very soon as mgorny's PSU has died, please share an implementation even as a draft if you want this.) I'm probably missing something obvious, but can't lld just depend on LLVM in such a way that it always gets rebuilt in case LLVM gets rebuilt or when LLVM's USE flags change? No, not really. The closest thing is "=" USE-dep but that would just give user annoying errors when USE flags mismatch between LLVM and LLD. Doesn't help that these tools should ideally be able to rebuild themselves and not be in an intermediary broken state that require gcc/ld.bfd to build again. I don't think juggling rebuilds is going to work out on the long run. Even rebuild order matters (e.g. LLVM_TARGETS --changed/new-use rebuilds doesn't always save clang from breakage). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=698ec80663c740fa7b03ec11821bfd7189d10bf5 commit 698ec80663c740fa7b03ec11821bfd7189d10bf5 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-26 02:12:19 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-26 02:12:19 +0000 profiles/base: add bug ref to LLVM_TARGETS force Bug: https://bugs.gentoo.org/767700 Signed-off-by: Sam James <sam@gentoo.org> profiles/base/package.use.force | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |