GHC does not compile on pkgsMusl after the ld.gold change

[utdemir]

Describe the bug

GHC does not compile on pkgsMusl anymore, after #80466 is merged, failing with this error:

...
checking for dllwrap... no
checking for -objdump... objdump
checking for x86_64-unknown-linux-musl-gcc... /nix/store/wv11dyp6p1sk8il4wxqn3rd9bclhf9m8-gcc-wrapper-9.2.0/bin/cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/tmp/nix-build-ghc-8.6.5.drv-0/ghc-8.6.5':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
builder for '/nix/store/ydqgcy4yahnlahbazhj9r69j7ijwvnb3-ghc-8.6.5.drv' failed with exit code 1
17403: failed: NixPermanentFailure builder for '/nix/store/ydqgcy4yahnlahbazhj9r69j7ijwvnb3-ghc-8.6.5.drv' failed with exit code 1
error: build of '/nix/store/ydqgcy4yahnlahbazhj9r69j7ijwvnb3-ghc-8.6.5.drv' on 'ssh://nxb-4' failed: builder for '/nix/store/ydqgcy4yahnlahbazhj9r69j7ijwvnb3-ghc-8.6.5.drv' failed with exit code 1
builder for '/nix/store/ydqgcy4yahnlahbazhj9r69j7ijwvnb3-ghc-8.6.5.drv' failed with exit code 1
error: build of '/nix/store/ydqgcy4yahnlahbazhj9r69j7ijwvnb3-ghc-8.6.5.drv' failed

To Reproduce

$ nix-build -A pkgsMusl.haskell.packages.ghc865.ghc

I only confirmed ghc865 to be caused by the commit I mentioned. GHC 8.8 and GHC 8.10 also doesn't compile with pkgsMusl currently, but I don't know if this exact commit is the cause since compiling them takes a long time.

Edit: I reproduced the issue also with ghc882 and ghc8101.

cc @peti @adamse @nh2

[nh2]

I have also seen this failure. I also believe to have posted about it on some issue, but not sure which one it was (and maybe my message did not get submitted successfully).

[domenkozar]

Does musl support gold linker?

[utdemir]

Looks relevant: #49071 (ld.gold crashes or produces invalid executables when Musl is used as a libc)

[adamse]

If #49071 is still current it we should use -fpie (for compiling C) and -pie for linking? Or should we disable ld.gold whith musl libc?

Disabling ld.gold for musl seems like the simplest and least invasive option.

Thoughts?

[Mic92]

A stacktrace/coredump might be helpful. You can get one with coredumpctl usually.

[cdepillabout]

Hopefully fixed in #84741 by @adamse

[nh2]

Did you see that on my bug report on https://sourceware.org/bugzilla/show_bug.cgi?id=23856 somebody commented:

I've hit this on Alpine too and adding -fPIE to CFLAGS does indeed fix his.

Perhaps we could try that as well (I think that's what was suggested above)?

@bgamari do you have an opinion on that?

[adamse]

@nh2, that was indeed the other suggestion I meant above.

For the PIE solution, wouldn't that mean all Haskell programs built by this GHC would have to be PIE too or we'd have to use a different linker when using GHC?

[nh2]

For the PIE solution, wouldn't that mean all Haskell programs built by this GHC would have to be PIE too or we'd have to use a different linker when using GHC?

I do not know the answer currently, but maybe somebody else does?

[bgamari]

Indeed it sounds like the proposed workaround would be to link all executables with -fPIE. As a user given the choice between this workaround and falling back to BFD LD, I would probably prefer the former. gold is just that much faster.

[adamse]

Is it possible to instruct GHC to link with -fPIE by default?

[bgamari]

Yes, IIRC you can set CONF_LD_LINKER_OPTS_STAGE2 when invoking ’configure’. The flags you pass should end up in the resulting compiler's ’settings’ file.