Created attachment 897929 [details] emerge --info media-sound/mpd Today's update brought media-sound/mpd-0.23.13-r1. It failed early during the compilation, the build.log complaining that the build only supports a limited list of linkers, and specifically not ld.bfd. Which would be fine except AFAIK I'm using mold everywhere, and that was explicitly listed. Trying my usual /etc/portage/package.env override for lld failed with the same message, despite it being listed. Digging around, I came across /etc/clang/gentoo-runtimes.cfg which specifies --fuse-ld=bfd so I tried changing it to --fuse-ld=mold, and that cured it. So something weird is going on, as it appears my usual override (see emerge --info attached) isn't being recognised by mpd, though I'm sure it works elsewhere.
No build.log?
Tomorrow (I need to recreate it and it's getting late)
Created attachment 897996 [details] media-sound/mpd-foo/temp directory tarball I made the tarball as there seem to be some additional relevant files than just build.log.
Created attachment 897997 [details] mpd emerge temp directory tarball Same contents as previous, but with a name that bugzilla might handle better than "log"
C compiler for the host machine: clang (clang 17.0.6 "clang version 17.0.6") C linker for the host machine: clang ld.mold 2.31.0 C++ compiler for the host machine: clang++ (clang 17.0.6 "clang version 17.0.6") C++ linker for the host machine: clang++ ld.mold 2.31.0 [...] ERROR: LLVM's ThinLTO only works with gold, lld, lld-link, ld64 or mold, not ld.bfd A full log can be found at /var/tmp/portage/media-sound/mpd-0.23.15-r1/work/mpd-0.23.15-build/meson-logs/meson-log.txt I'm not sure how this happens. With a test project, meson works fine via: CC="clang" LDFLAGS="-fuse-ld=mold" meson setup -Db_lto=true -Db_lto_mode=thin builddir/ The error message is an internal error: # ThinLTO requires the use of gold, lld, ld64, lld-link or mold 1.1+ if isinstance(self.linker, (MoldDynamicLinker)): # https://github.com/rui314/mold/commit/46995bcfc3e3113133620bf16445c5f13cd76a18 if not mesonlib.version_compare(self.linker.version, '>=1.1'): raise mesonlib.MesonException("LLVM's ThinLTO requires mold 1.1+") elif not isinstance(self.linker, (AppleDynamicLinker, ClangClDynamicLinker, LLVMDynamicLinker, GnuGoldDynamicLinker)): raise mesonlib.MesonException(f"LLVM's ThinLTO only works with gold, lld, lld-link, ld64 or mold, not {self.linker.id}")
Hmm, as per my original Description, that error message would appear to imply "self linker" has been built from the information in /etc/clang/gentoo-runtimes.cfg (leading to an ld.bfd linker), and not been overridden by LDFLAGS in this instance. Apologies - you probably had already worked that out, but I thought I better say it in case my Description wasn't clear.
Right, the problem is that the logs identify the linker model as "clang++ ld.mold 2.31.0" and in theory it should never be able to print "ld.mold" there unless we are indeed inside MoldDynamicLinker. It is only class MoldDynamicLinker(GnuDynamicLinker) that has a self.id = 'ld.mold', nothing else inherits from it, so the meson codebase shouldn't be able to hit this error under such a circumstance. The linker id shouldn't be getting recalculated or reset at any point, and it was definitely detected correctly at the start...
By coincidence to the flurry of assignments yesterday, I happened to run into this problem again yesterday, this time with app-arch/zstd. I did some digging, and found a bug (sorry, can't find it again, I've tried) with a cure to set USE=default-lld on llvm-core/clang-common (or maybe clang-runtime, I think it was about it moving). This "works" for me, in that IIUC, it can now emerge zstd with lto, but it's not using mold. (What it's done, of course, is set /etc/clang/gentoo-runtimes.cfg to specify --fuse-ld=lld, which is what my manual edit in the original problem description was doing, except that was for mold not lld.) It definitely seems to be that meson prefers the setting in /etc/clang/gentoo-runtimes.cfg. It might be advantageous to add a USE=default-mold to clang-common, though better would be a way to get meson to correctly interpret LDFLAGS="-fuse-ld=mold" in the first place.
(In reply to Paul Gover from comment #8) > It definitely seems to be that meson prefers the setting in > /etc/clang/gentoo-runtimes.cfg. It might be advantageous to add a > USE=default-mold to clang-common, though better would be a way to get meson > to correctly interpret LDFLAGS="-fuse-ld=mold" in the first place. The effective implication of /etc/clang/gentoo-runtimes.cfg is that those arguments are implicitly considered as command line arguments of clang, even without passing them in LDFLAGS. I'm not sure why this should matter to meson -- we should be using LDFLAGS everywhere and I can't trigger the issue manually. I mean, obviously you managed to hit it anyway, but... nothing about /etc/clang/gentoo-runtimes.cfg helps me better understand *why* and *how* it occurs. You could achieve the same workaround by placing a shell script earlier in $PATH called "clang", that runs `exec /usr/bin/clang -fuse-ld=mold "$@"`. The basic idea is that you are "smuggling" in an argument in a way that is very "difficult" to ignore.
