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.

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

Choice of linker should consider whether it supports LDFLAGS #9828

Closed
hseg opened this issue Mar 21, 2024 · 5 comments
Closed

Choice of linker should consider whether it supports LDFLAGS #9828

hseg opened this issue Mar 21, 2024 · 5 comments

Comments

@hseg
Copy link

hseg commented Mar 21, 2024

Describe the bug
network, time, unix fail to build when LDFLAGS contains -Wl,-z,pack-relative-relocs. This is because cabal builds them with LD=ld.gold, which doesn't support this feature. This breaks builds on Arch Linux, whose default build configuration recently added the flag to LDFLAGS.

To Reproduce
Steps to reproduce the behavior:

export LDFLAGS='-Wl,-z,pack-relative-relocs'
git clone https://github.com/haskell/network
cabal configure
cabal build

Expected behavior

cabal build tests $LD $LDFLAGS works before picking it, and then either warns ld.gold doesn't support LDFLAGS as set or Could not find working linker

System information

  • Operating system: Arch Linux
  • cabal, ghc versions: cabal-install 3.10.2.1, ghc 9.8.2

Additional context
Reported in Arch Linux upstream as well, and in GHC which had a similar issue. Also mistakenly reported this in stack due to initial confusion as to the cause.

@andreabedini
Copy link
Collaborator

Is cabal calling the linker here or GHC?

@erikd You looked at linker feature detection before. Do you have any take on this?

@hseg
Copy link
Author

hseg commented Apr 9, 2024

Frustratingly, am having difficulty reproducing, though I updated both ghc and cabal recently, so that might be behind it. In particular, the ghc I installed was with ghcup after haskell/ghcup-hs#1032, supporting the hypothesis that it's GHC's calling the linker that was at issue. Testing...

@hseg
Copy link
Author

hseg commented Apr 9, 2024

OK, it indeed seems to be a GHC issue rather than a cabal issue, sorry for the noise.
To reproduce, for pkg in [network, unix, time], cabalVer in [3.10.2.1,3.10.3.0] and ghcVer in [9.6.4]:

ghcup install ghc "$ghcVer" -- --enable-ld-override
ghcup install cabal "$cabalVer"
ghcup set ghc "$ghcVer"
ghcup set cabal "$cabalVer"
export LDFLAGS='-Wl,-z,pack-relative-relocs'
git clone https://github.com/haskell/"$pkg"
cd "$pkg"
autoreconf -i
cabal configure
cabal build

With these parameters, I can reproduce (eg for unix):

Build profile: -w ghc-9.6.4 -O1
In order, the following will be built (use -v for more details):
 - unix-2.8.5.1 (lib:unix, test:FdReadBuf001, test:ForkProcess01, test:Posix004, test:Posix009, test:Posix014, test:PutEnv001, test:ResourceLimit, test:Semaphore001, test:Semaphore002, test:SemaphoreInterrupt, test:Signals002, test:Signals004, test:T13660, test:T8108, test:Terminal, test:unix-tests) (first run)
Configuring unix-2.8.5.1...
configure: WARNING: unrecognized options: --with-compiler
checking for gcc... /usr/bin/gcc
checking whether the C compiler works... no
configure: error: in '/tmp/unix/dist-newstyle/build/x86_64-linux/ghc-9.6.4/unix-2.8.5.1/build':
configure: error: C compiler cannot create executables
See 'config.log' for more details
Error: cabal: Failed to build unix-2.8.5.1. The failure occurred during the
configure step. The build process terminated with exit code 77

It's quite probable nothing needs to be done here, but I leave the closure decision to you.

@gbaz
Copy link
Collaborator

gbaz commented Apr 9, 2024

Seems to be resolved upstream: https://gitlab.haskell.org/ghc/ghc/-/commit/32a8103f3b3e22907fdd67b69c919c5251d8cc20

Let's optimistically close.

@gbaz gbaz closed this as completed Apr 9, 2024
@andreabedini
Copy link
Collaborator

OK, it indeed seems to be a GHC issue rather than a cabal issue, sorry for the noise.

Nothing to be sorry about. It's a common misconception that cabal invokes the linker. In the most common cases it doesn't and linking is left to ghc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants