https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sys-apps/fwupd-efi-1.4 calls ld directly. Discovered on: amd64 (internal ref: ci) NOTE: As per QA policy, toolchain tools must not be called directly because they can cause issue in cross-compiling and because is not possible use a different LD implementation (like llvm-link). To reproduce, please use sys-devel/gcc-config[-native-symlinks], sys-devel/binutils-config[-native-symlinks].
Created attachment 849317 [details] build.log build log and emerge --info
Created attachment 849319 [details] 1-meson-log.txt 1-meson-log.txt
Error(s) that match a know pattern: efi/meson.build:226:0: ERROR: Program 'ld.bfd' not found or not executable efi/meson.build:90: WARNING: Cannot find SBAT section in /usr/lib64/elf_x86_64_efi.lds, using local copy Program genpeimg found: NO
The problem here is not that the build scripts call ld directly (looking at src_configure output in build.log shows that meson has correctly identified the linker as x86_64-pc-linux-gnu-gcc as specified in LD) but rather, that it assumes the chosen linker can be called by an executable whose name matches the linker ID - ld.bfd in this case. This outright breaks on systems where such symlinks are not created (as shown here), and might invoke an incorrect linker on systems where they do exist. Still, something will have to be done about it. I reckon that unless upstream comes with a proper fix soon, I'll just reinstate the old approach of having a Meson option to specify the linker.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3e68014936059256d40d745a4e60dd46aeca52f9 commit 3e68014936059256d40d745a4e60dd46aeca52f9 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2023-02-27 12:53:56 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2023-02-27 13:15:23 +0000 sys-apps/fwupd-efi: restore the old option for setting the linker Between 1.3 and 1.4, fwupd-efi upstream phased this option out in favour of using standard Meson toolchain management for both the compiler and the linker. However, the transition has not been completed yet and the linking phase still involves a custom target explicitly calling the linker executable - and the way the name of said executable is determined at the moment is not entirely robust. Closes: https://bugs.gentoo.org/892339 Signed-off-by: Marek Szuba <marecki@gentoo.org> .../files/fwupd-efi-1.4-efi_ld_override.patch | 26 ++++++++++++++++++++++ sys-apps/fwupd-efi/fwupd-efi-1.4.ebuild | 7 +++++- 2 files changed, 32 insertions(+), 1 deletion(-)
