Wrong defaulting linker when LD env.var. is set

Summary

Upon GHC installation there is a mechanism to choose the best (fastest?) linker that is available in the system as the default one. The chosen linker is stored under lib/ghc-version/settings. For example, an extract taken from the settings using the gold linker as default one:

,("ld command", "ld.gold")
,("Merge objects command", "ld.gold")
,("ld is GNU ld", "YES")
,("C compiler link flags", "-fuse-ld=gold")

If the LD variable is set during GHC installation, these settings end up misconfigured, as in the example:

,("ld command", "ld.gold")
,("Merge objects command", "ld.gold")
,("ld is GNU ld", "YES")
,("C compiler link flags", "")

The choice is the correct one since ld.gold is installed but Notice the empty C compiler link flags. Because ghc links through gcc ("C compiler command", "gcc"), and gcc -print-prog-name=ld returns ld, the linker that will be picked up for linking would be whatever ld is in the PATH, instead of the default choice (ld.gold in this case).

Under ArchLinux (and I suspect other systems as well) the /usr/bin/ld is a hardlink to /usr/bin/ld.bfd which means the bfd will be picked up instead of the default choice (ld.gold in this case).

@hsyl20 suggest that

Looking into .m4, it's because when the LD shell variable is set, it doesn't call FP_CC_LINKER_FLAG_TRY, which is the function that has for side-effect to set the GccUseLdOpt variable to "-fuse-ld=$1"."

Steps to reproduce

export LD=ld.gold
ghcup install ghc version

~/.ghcup/ghc/version/lib/version/settings picks up ld.gold but contains an empty C compiler link flags.

Expected behavior

The expected behaviour is to also correctly set the C compiler link flag in the settings, e.g.

,("C compiler link flags", "-fuse=ld.gold")

Environment

• GHC version used: ghcup version of ghc 8.10.7 and ghc 9.2.3

Optional:

• Operating System: Linux (ArchLinux)
• System Architecture: x86-64