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 theLD
shell variable is set, it doesn't callFP_CC_LINKER_FLAG_TRY
, which is the function that has for side-effect to set theGccUseLdOpt
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