| Summary: | multilib.eclass: use proper LDFLAGS for compiler driver (stop passing raw LDFLAGS via LD) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sam James <sam> |
| Component: | Eclasses | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | pageexec |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://github.com/gentoo/gentoo/pull/33114 https://bugs.gentoo.org/show_bug.cgi?id=515694 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 908692 | ||
| Bug Blocks: | |||
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
```
|
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.