Skip to content
Snippets Groups Projects

Linker broken on M1 Mac in ghc-9.2.2

    • Closed Issue created by Richard Eisenberg @rae

    I have a GHC 9.2.2 as installed by ghcup. It cannot link:

    rae:15:01:01 ~/temp/bug> cat Main.hs
module Main where

main = putStrLn "Hello, world!"
rae:15:01:07 ~/temp/bug> ghc Main.hs
Linking Main ...
ld64.lld: error: unknown argument '--gc-sections'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
rae:15:01:11 ~/temp/bug>

    My GHC 9.2.1 works, both the one I installed myself and ghcup's version.

    Help?

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Richard Eisenberg added aarch64-darwin linking needs triage labels

      added aarch64-darwin linking needs triage labels

    • Richard Eisenberg mentioned in merge request !8224 (closed)

      mentioned in merge request !8224 (closed)

    • Matthew Pickering
      Matthew Pickering @mpickering ·
      Developer

      What does ghc --info say?

    • Matthew Pickering added info needed label

      added info needed label

    • Ben Gamari removed needs triage label

      removed needs triage label

    • Ben Gamari added Pnormal Tbug labels

      added Pnormal Tbug labels

    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      Indeed we shouldn't be trying to use --gc-sections on Darwin. The only time we should use this flag is when linking an executable with GNU ld, which is clearly not the case here. It would indeed be useful to have the output from ghc --info and ld --version.

    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      I have tried to reproduce this using the upstream 9.2.2 bindist on an M1 mac but failed.

      @rae, is it possible that you have multiple linkers installed (e.g. perhaps binutils is installed through brew)? Perhaps configure found one but GHC is using the other?

    • Richard Eisenberg
      Richard Eisenberg @rae ·
      Author Developer

      @rae, is it possible that you have multiple linkers installed (e.g. perhaps binutils is installed through brew)?

      Anything is possible.

      rae:16:19:41 ~/temp/bug> ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts","")
 ,("C compiler command","gcc")
 ,("C compiler flags","--target=arm64-apple-darwin ")
 ,("C++ compiler flags","--target=arm64-apple-darwin ")
 ,("C compiler link flags","--target=arm64-apple-darwin  -fuse-ld=lld")
 ,("C compiler supports -no-pie","NO")
 ,("Haskell CPP command","gcc")
 ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs")
 ,("ld command","ld.lld")
 ,("ld flags","")
 ,("ld supports compact unwind","NO")
 ,("ld supports build-id","NO")
 ,("ld supports filelist","NO")
 ,("ld is GNU ld","YES")
 ,("Merge objects command","ld.lld")
 ,("Merge objects flags","-r")
 ,("ar command","ar")
 ,("ar flags","qcls")
 ,("ar supports at file","NO")
 ,("ranlib command","ranlib")
 ,("otool command","otool")
 ,("install_name_tool command","install_name_tool")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("unlit command","/Users/rae/.ghcup/ghc/9.2.2/lib/ghc-9.2.2/lib/bin/unlit")
 ,("cross compiling","NO")
 ,("target platform string","aarch64-apple-darwin")
 ,("target os","OSDarwin")
 ,("target arch","ArchAArch64")
 ,("target word size","8")
 ,("target word big endian","NO")
 ,("target has GNU nonexec stack","NO")
 ,("target has .ident directive","YES")
 ,("target has subsections via symbols","NO")
 ,("target has RTS linker","YES")
 ,("Unregisterised","NO")
 ,("LLVM target","arm64-apple-darwin")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("LLVM clang command","clang")
 ,("Use interpreter","YES")
 ,("Support SMP","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p debug_p")
 ,("Tables next to code","YES")
 ,("Leading underscore","YES")
 ,("Use LibFFI","YES")
 ,("RTS expects libdw","NO")
 ,("Project version","9.2.2")
 ,("Project Git commit id","fbaee70d380973f71fa6e9e15be746532e5a4fc5")
 ,("Booter version","8.10.7")
 ,("Stage","2")
 ,("Build platform","aarch64-apple-darwin")
 ,("Host platform","aarch64-apple-darwin")
 ,("Target platform","aarch64-apple-darwin")
 ,("Have interpreter","YES")
 ,("Object splitting supported","NO")
 ,("Have native code generator","YES")
 ,("Target default backend","NCG")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Support Backpack","YES")
 ,("Requires unified installed package IDs","YES")
 ,("Uses package keys","YES")
 ,("Uses unit IDs","YES")
 ,("GHC Dynamic","YES")
 ,("GHC Profiled","NO")
 ,("Debug on","NO")
 ,("LibDir","/Users/rae/.ghcup/ghc/9.2.2/lib/ghc-9.2.2/lib")
 ,("Global Package DB","/Users/rae/.ghcup/ghc/9.2.2/lib/ghc-9.2.2/lib/package.conf.d")
 ]
rae:16:19:47 ~/temp/bug>

      There was a mention of configure, but I did not invoke configure at all: this was installed via ghcup (which might internally invoke configure -- I don't know).

    • Matthew Pickering
      Matthew Pickering @mpickering ·
      Developer

      What does ld --version say?

    • Richard Eisenberg
      Richard Eisenberg @rae ·
      Author Developer 
      rae:16:19:47 ~/temp/bug> ld --version
ld: unknown option: --version
    • Richard Eisenberg
      Richard Eisenberg @rae ·
      Author Developer 
      rae:16:44:48 ~/temp/bug> ld.lld --version
Homebrew LLD 13.0.1 (compatible with GNU linkers)
    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      Indeed it sounds like you have ld.lld installed via Homebrew, which confuses configure. There appears to be two bugs here:

      • Somehow configure detects ld.lld yet clang is still using the system's linker. Something must have gone very wrong to get into this state.
      • I suspect we should probably not use configure's linker-override logic on Darwin since we really never want to use anything but the system's toolchain on that platform.
    • Ben Gamari assigned to @bgamari

      assigned to @bgamari

    • Richard Eisenberg mentioned in issue #21712 (closed)

      mentioned in issue #21712 (closed)

    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      The cause of this regression in %9.2.2 was 0299de81. Prior to that change things worked but only accidentally. Specifically, the m4/find_ld.m4 logic would attempt to probe lld but would fail to recognize the version string as lld and consequently give up. However, now since that commit we conclude that lld is usable.

      Further, ld.lld's --version string contains (compatible with GNU linkers), which then causes the logic in m4/fp_prog_ld_is_gnu.m4 to concluded that the linker is a GNU bfd linker. GHC then in turn uses that knowledge to conclude that the linker supports --gc-sections. However, this is fine as ld.lld does indeed support --gc-sections, just as ld.bfd would.

      GHC consequently passes -fuse-ld=lld -Wl,--gc-sections to gcc (which is Apple's clang). However, gcc then decides to use ld64.lld (not ld.lld as configure found), which does not support --gc-sections. Incidentally, ld64.lld's version string does not contain the string (compatible with GNU linkers) (which indeed it is not).

    • Richard Eisenberg
      Richard Eisenberg @rae ·
      Author Developer

      Some output @bgamari asked for in a very helpful live debugging session (thank you!):

      rae:16:42:36 ~/temp> which gcc
/usr/bin/gcc
rae:16:44:09 ~/temp> gcc --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
rae:16:44:11 ~/temp> which ld
/usr/bin/ld
rae:16:44:13 ~/temp> ld -v
@(#)PROGRAM:ld  PROJECT:ld64-764
BUILD 11:29:07 May 17 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 13.1.6, (clang-1316.0.21.2.5) (static support for 28, runtime is 28)
TAPI support using: Apple TAPI version 13.1.6 (tapi-1316.0.7.3)
rae:16:44:15 ~/temp> which ld64.lld
/opt/homebrew/opt/llvm/bin/ld64.lld
rae:16:44:18 ~/temp> ld64.lld -v
ld64.lld: error: must specify -arch
rae:16:44:26 ~/temp> ld64.lld --version
Homebrew LLD 13.0.1
rae:16:44:31 ~/temp> which ld.lld
/opt/homebrew/opt/llvm/bin/ld.lld
rae:16:44:45 ~/temp> ld.lld -v
Homebrew LLD 13.0.1 (compatible with GNU linkers)
rae:16:44:49 ~/temp> ld.lld --version
Homebrew LLD 13.0.1 (compatible with GNU linkers)
      • Ben Gamari
        Ben Gamari @bgamari ·
        Maintainer

        As a temporary workaround, one can pass --disable-ld-override to the binary distribution configure script. This will disable the linker discovery logic and use the system's default linker.

      • Carter Schonwald
        Carter Schonwald @carter ·
        Developer

        i think i hit this very same issue. its nasty and somehow even doing that one step isn't quite complete in fixing the generated settings file

        clang: error: invalid linker name in argument '-fuse-ld=lld'
ghc-9.4.3: `gcc' failed in phase `Linker'. (Exit code: 1)
Error: cabal: Failed to build exe:happy from happy-1.20.0. See the build log
above for details.
Failed to build exe:alex from alex-3.2.7.1. See the build log above for
details.
      • Carter Schonwald
        Carter Schonwald @carter ·
        Developer

        i get past that, and i get errors instead about gc-sections

        
ld: unknown option: --gc-sections
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ghc-9.4.3: `clang' failed in phase `Linker'. (Exit code: 1)
Error: cabal: Failed to build exe:happy from happy-1.20.0. See the build log
above for details.
Failed to build exe:alex from alex-3.2.7.1. See the build log above for
details.
      • Please register or sign in to reply
    • Ben Gamari mentioned in issue haskell/ghcup-hs#377 (closed)

      mentioned in issue haskell/ghcup-hs#377 (closed)

    • duck mentioned in issue #21873

      mentioned in issue #21873

    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    Please register or sign in to reply