In multilib_toolchain_setup, multilib.eclass currently does: ``` if [[ ${ABI} != ${DEFAULT_ABI} ]] ; then [...] export LD="$(tc-getLD) $(get_abi_LDFLAGS)" [...] ``` In profiles, we currently have: ``` $ rg LDFLAGS.*\-m profiles/ profiles/arch/loong/make.defaults:39:LDFLAGS_lp64d="-m elf64loongarch" profiles/arch/sparc/make.defaults:16:LDFLAGS_sparc64="-m elf64_sparc" profiles/arch/sparc/make.defaults:20:LDFLAGS_sparc32="" # setting it would make gcc use -m32 and -m64 at the same time profiles/arch/riscv/make.defaults:30:LDFLAGS_lp64d="-m elf64lriscv" profiles/arch/riscv/make.defaults:36:LDFLAGS_lp64="-m elf64lriscv_lp64" profiles/arch/riscv/make.defaults:42:LDFLAGS_ilp32d="-m elf32lriscv" profiles/arch/riscv/make.defaults:48:LDFLAGS_ilp32="-m elf32lriscv_ilp32" profiles/arch/powerpc/ppc64/make.defaults:25:LDFLAGS_ppc64="-m elf64ppc" profiles/arch/powerpc/ppc64/make.defaults:29:LDFLAGS_ppc="-m elf32ppc" profiles/arch/amd64/make.defaults:27:LDFLAGS_amd64="-m elf_x86_64" profiles/arch/amd64/make.defaults:32:LDFLAGS_x86="-m elf_i386" profiles/arch/amd64/make.defaults:37:LDFLAGS_x32="-m elf32_x86_64" ``` We should fix profiles + multilib.eclass at the same time. We can't do this until linux-mod-r0.eclass is gone though.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bb2d045c02a6ca647ef3280f4987cbc0d14e5a7e commit bb2d045c02a6ca647ef3280f4987cbc0d14e5a7e Author: Sam James <sam@gentoo.org> AuthorDate: 2023-09-28 23:27:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-09-30 09:38:40 +0000 toolchain.eclass: rework bootstrapping logic * Build stage1 compiler with user's CFLAGS. This consistently ends up saving at least 15 minutes for me on a fast amd64 machine and should save more on slower machines and architectures. There's only any risk here if the host compiler is ancient/very buggy and even then, you get a failed bootstrap later on. The GCC developers, per the linked bug, end up using STAGE1_CFLAGS="-O2" anyway to speed up the process so it's not like this is untested at all. mattst88 actually brought this up.. 10 years ago (bug #477548). Let's try make that right now. * Respect LDFLAGS for target libraries for native builds. Not touching this for cross builds, at least for now, as it's a bit more delicate. (Unfortunately, we have to put a hack in here for now until we can fix multilib.eclass - see bug #914881). Bug: https://gcc.gnu.org/PR111619 Bug: https://bugs.gentoo.org/914881 Closes: https://bugs.gentoo.org/477548 Closes: https://bugs.gentoo.org/831423 Closes: https://bugs.gentoo.org/840392 Apologies-to: Matt Turner <mattst88@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 52 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 35 insertions(+), 17 deletions(-)
When we fix this, we can improve this in dev-debug/perf too: ``` # perf directly invokes LD for linking without going through CC, on mips # it is required to specify the emulation. port of below buildroot patch # https://patchwork.ozlabs.org/project/buildroot/patch/20170217105905.32151-1-Vincent.Riera@imgtec.com/ local linker="$(tc-getLD)" if use mips then if use big-endian then use abi_mips_n64 && linker+=" -m elf64btsmip" use abi_mips_n32 && linker+=" -m elf32btsmipn32" use abi_mips_o32 && linker+=" -m elf32btsmip" else use abi_mips_n64 && linker+=" -m elf64ltsmip" use abi_mips_n32 && linker+=" -m elf32ltsmipn32" use abi_mips_o32 && linker+=" -m elf32ltsmip" fi fi ```