Bug 914881 – multilib.eclass: use proper LDFLAGS for compiler driver (stop passing raw LDFLAGS via LD)

• Status: CONFIRMED
• Product: Gentoo Linux

[Description Sam James 2023-09-28 09:16:26 UTC]

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.

[Comment 1 Larry the Git Cow 2023-09-30 09:38:55 UTC]

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 <[e-mail]>
AuthorDate: 2023-09-28 23:27:06 +0000
Commit:     Sam James <[e-mail]>
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 <[e-mail]>
    Signed-off-by: Sam James <[e-mail]>

 eclass/toolchain.eclass | 52 +++++++++++++++++++++++++++++++++----------------
 1 file changed, 35 insertions(+), 17 deletions(-)