Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Disable GHCs aggressive selection of ld.gold #1032

Open
hasufell opened this issue Mar 23, 2024 · 6 comments
Open

Disable GHCs aggressive selection of ld.gold #1032

hasufell opened this issue Mar 23, 2024 · 6 comments

Comments

@hasufell
Copy link
Member

hasufell commented Mar 23, 2024 •
edited
Loading

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:

Sparked by discussion: https://gitlab.haskell.org/ghc/ghc/-/issues/24565
hasufell added a commit that referenced this issue Mar 23, 2024
@hasufell
Pass --disable-ld-override when installing/compiling GHC
5f243d0 
Fixes #1032

Users can still run 'ghcup install ghc <ver> -- enable-ld-override'
@hasufell
Copy link
Member Author

#1033

@hasufell hasufell mentioned this issue Mar 31, 2024
Open
@hseg
Copy link

hseg commented Apr 6, 2024 •
edited
Loading

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.

@hseg hseg mentioned this issue Apr 9, 2024
Closed
archlinux-github pushed a commit to archlinux/aur that referenced this issue May 2, 2024
@hseg
Force building with ghc-9.6.5
72fa9a2 
The default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would *not* check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked
using this LD.

A fix[1] for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's
installed using the current ghcup HEAD (starting with 7a684ad[2]) will
have `--disable-ld-override` passed, which also fixes the issue.

[1] - https://gitlab.haskell.org/ghc/ghc/-/issues/24565
[2] - haskell/ghcup-hs#1032
archlinux-github pushed a commit to archlinux/aur that referenced this issue May 5, 2024
@hseg
Force building with ghc-9.6.5
f297b91 
The default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would *not* check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked
using this LD.

A fix[1] for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's
installed using the current ghcup HEAD (starting with 7a684ad[2]) will
have `--disable-ld-override` passed, which also fixes the issue.

[1] - https://gitlab.haskell.org/ghc/ghc/-/issues/24565
[2] - haskell/ghcup-hs#1032
archlinux-github pushed a commit to archlinux/aur that referenced this issue May 5, 2024
@hseg
Force building with ghc-9.6.5
3934789 
The default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would *not* check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked
using this LD.

A fix[1] for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's
installed using the current ghcup HEAD (starting with 7a684ad[2]) will
have `--disable-ld-override` passed, which also fixes the issue.

[1] - https://gitlab.haskell.org/ghc/ghc/-/issues/24565
[2] - haskell/ghcup-hs#1032
archlinux-github pushed a commit to archlinux/aur that referenced this issue May 5, 2024
@hseg
Force building with ghc-9.6.5
0b9ab3f 
The default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would *not* check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked
using this LD.

A fix[1] for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's
installed using the current ghcup HEAD (starting with 7a684ad[2]) will
have `--disable-ld-override` passed, which also fixes the issue.

[1] - https://gitlab.haskell.org/ghc/ghc/-/issues/24565
[2] - haskell/ghcup-hs#1032
archlinux-github pushed a commit to archlinux/aur that referenced this issue May 5, 2024
@hseg
Force building with ghc-9.6.5
43e5c55 
The default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would *not* check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked
using this LD.

A fix[1] for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's
installed using the current ghcup HEAD (starting with 7a684ad[2]) will
have `--disable-ld-override` passed, which also fixes the issue.

[1] - https://gitlab.haskell.org/ghc/ghc/-/issues/24565
[2] - haskell/ghcup-hs#1032
archlinux-github pushed a commit to archlinux/aur that referenced this issue May 5, 2024
@hseg
Force building with ghc-9.6.5
f9994d0 
The default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would *not* check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked
using this LD.

A fix[1] for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's
installed using the current ghcup HEAD (starting with 7a684ad[2]) will
have `--disable-ld-override` passed, which also fixes the issue.

[1] - https://gitlab.haskell.org/ghc/ghc/-/issues/24565
[2] - haskell/ghcup-hs#1032
@mpickering
Copy link
Contributor

It seems that 2a7f32e 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
Copy link
Member Author

hasufell commented Jul 8, 2024 •
edited
Loading

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

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

@mpickering
Copy link
Contributor

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

archlinux-github pushed a commit to archlinux/aur that referenced this issue Jul 17, 2024
@hseg
Force building with ghc-9.6.5
7afb9d7 
Pull in the ghc-9.6 port branch for now.

The default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would *not* check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked
using this LD.

A fix[1] for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's
installed using the current ghcup HEAD (starting with 7a684ad[2]) will
have `--disable-ld-override` passed, which also fixes the issue.

[1] - https://gitlab.haskell.org/ghc/ghc/-/issues/24565
[2] - haskell/ghcup-hs#1032
@hasufell
Copy link
Member Author

Repoening.

@hasufell hasufell reopened this Jul 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mpickering @hasufell @hseg