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...
