Disable GHCs aggressive selection of `ld.gold`

[hasufell]

GHC constantly tries to overwrite distro defaults and selects ld.gold very aggressively even if ld.bfd is the system default.

Major source distros advice against using ld.gold as default and we should follow their lead.

As such, I propose to:

• pass --disable-ld-override
• revert https://github.com/haskell/ghcup-hs/issues/967 and just go with whatever distro default is set

Sparked by discussion: https://gitlab.haskell.org/ghc/ghc/-/issues/24565

[hasufell]

https://github.com/haskell/ghcup-hs/pull/1033

[hseg]

Thanks for that, double-checked that ghc --info emits ("Merge objects command", "ld") (though oddly enough, it still seems to think ("ld is GNU ld", "YES") -- I don't know if that's correct, but that's a GHC bug if it is). Now I just need to figure out/prod stack to enable the same (given that https://gitlab.haskell.org/ghc/ghc/-/issues/24565 was triggered when running a stack-vendored ghc in a packaging context, not my usual usage of a ghcup-vendored ghc in a dev context)

EDIT: First result when googling this https://www.haskell.org/ghcup/guide/#stack-integration. Probably best solution for now.

[mpickering]

It seems that 2a7f32ec8caf638a9c14c6ba223e2a489db9620c reverts the change to use --disable-ld-override "for now".

Is the plan to enable --disable-ld-override in future, is there an issue which is block it being used now?

[hasufell]

I want some more time to pass and reflect on it.

@alt-romes talked to me about that at ZuriHac.

[mpickering]

Thanks sounds good, just wanted to check in about what the status was there.

[hasufell]

Repoening.

[sim590]

binutils 2.44 has deprecated ld.gold. It had the effect of removing it from users' computer after an upgrade on Debian for example and a previously installed GHC version with ghcup before the update now doesn't work anymore after the update as it fails to find ld.gold when trying to compile C code for a Haskell package that requires it.

The funny thing though is that cabal fails issuing an error message that has nothing to do with this as it states that it can't find the C package it requires with pkg-config even though pkg-config reports the right paths and flags. You actually have to pass the extra verbose -v3 flag to cabal to actually get GHC to show that it failed finding the linker which made some folks I know on Debian look for a while for an answer...

I don't know if it has been removed yet since this issue is still open, but I would also advise to not force ld.gold now that it's deprecated.

[hasufell]

Thanks. Reference: https://www.phoronix.com/news/GNU-Gold-Linker-Deprecated

I guess my intuition was right all along. We should respect the system ld, whatever it is.

[cartazio]

is the disable ld-override flag needed for 9.10 or 9.12? its hard to tell

[hasufell]

It's not "needed" in any sense, it just prevents GHC from handpicking and hardcoding it.

Issues can manifest when e.g.

• you had ld.gold installed
• you installed GHC
• your distro removed gold bc it's deprecated
• your GHC is now busted

This can't happen when you install GHC with said flag. It's now default in the upcoming ghcup release.

It also means GHC will use whatever ld points to.

[cartazio]

Great. It definitely made for bizarre breakage in ghc a few years back on osx

On Fri, May 16, 2025 at 1:34 PM Julian Ospald @.***> wrote:

hasufell left a comment (haskell/ghcup-hs#1032) https://github.com/haskell/ghcup-hs/issues/1032#issuecomment-2887314269

It's not "needed" in any sense, it just prevents GHC from handpicking and hardcoding it.

Issues can manifest when e.g.

• you had ld.gold installed
• you installed GHC
• your distro removeq gold bc it's deprecated
• your GHC is now busted

This can't happen when you install GHC with said flag. It's now default in the upcoming ghcup release.

It also means GHC will use whatever ld points to.

— Reply to this email directly, view it on GitHub https://github.com/haskell/ghcup-hs/issues/1032#issuecomment-2887314269, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABBQSNMX26M3GGBJWWIKD26YOTFAVCNFSM6AAAAAB5CFMYUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBXGMYTIMRWHE . You are receiving this because you commented.Message ID: @.***>

[cartazio]

Btw: where does the ghc bin dist put the generated settings file when you run configure? I lt seems to have changed

On Fri, May 16, 2025 at 7:47 PM Carter Schonwald @.***> wrote:

Great. It definitely made for bizarre breakage in ghc a few years back on osx

On Fri, May 16, 2025 at 1:34 PM Julian Ospald @.***> wrote:

hasufell left a comment (haskell/ghcup-hs#1032) https://github.com/haskell/ghcup-hs/issues/1032#issuecomment-2887314269

It's not "needed" in any sense, it just prevents GHC from handpicking and hardcoding it.

Issues can manifest when e.g.

• you had ld.gold installed
• you installed GHC
• your distro removeq gold bc it's deprecated
• your GHC is now busted

This can't happen when you install GHC with said flag. It's now default in the upcoming ghcup release.

It also means GHC will use whatever ld points to.

— Reply to this email directly, view it on GitHub https://github.com/haskell/ghcup-hs/issues/1032#issuecomment-2887314269, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABBQSNMX26M3GGBJWWIKD26YOTFAVCNFSM6AAAAAB5CFMYUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBXGMYTIMRWHE . You are receiving this because you commented.Message ID: @.***>

[hasufell]

On unix it's ~/.ghcup/ghc/9.12.2/lib64/ghc-9.12.2/lib/settings

[cartazio]

On unix it's ~/.ghcup/ghc/9.12.2/lib64/ghc-9.12.2/lib/settings

Sorry, I meant where does the bin dist configure step write it out. I couldn’t find it before I did a make install.