Can't use Stack on macOS/Apple silicon due to linker problem with --gc-sections

Learn
#1

I’m very new to this. I’m trying to use stack to run a tool. I have installed it via ghcup (ghcup installed view brew) on my Apple M1 running OS X Sonoma.

I cannot go through the basics: I follow the instructions found here The Haskell Tool Stack (Quick Start guide).

  • stack new my-project works smoothly.
  • when I run stuck build (n the my-project directory) I get the following error:
➜  my-project stack build                                  
[3 of 3] Linking /Users/carbonem/.stack/setup-exe-cache/aarch64-osx/tmp-Cabal-simple_6HauvNHV_3.8.1.0_ghc-9.4.7
ld: unknown options: --gc-sections 
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ghc-9.4.7: `gcc' failed in phase `Linker'. (Exit code: 1)

Error: [S-6374]
       While building simple Setup.hs (scroll up to its section to see the
       error) using:
       /Users/carbonem/.stack/programs/aarch64-osx/ghc-9.4.7/bin/ghc-9.4.7 -rtsopts -threaded -clear-package-db -global-package-db -hide-all-packages -package base -main-is StackSetupShim.mainOverride -package Cabal-3.8.1.0 /Users/carbonem/.stack/setup-exe-src/setup-6HauvNHV.hs /Users/carbonem/.stack/setup-exe-src/setup-shim-6HauvNHV.hs -o /Users/carbonem/.stack/setup-exe-cache/aarch64-osx/tmp-Cabal-simple_6HauvNHV_3.8.1.0_ghc-9.4.7
       Process exited with code: ExitFailure 1

Perhaps this is an obvious issue but I really cannot find out how to solve it. Please help :slight_smile:

Thank you.

2 Likes
#2

Look at these:

and try other similar searches here on this Discourse if needed:

Search results for '' - Haskell Community

to see if this problem has appeared before (and maybe for which a solution already exists).

1 Like
#3

I think that may be a bug in GHC. See these GHC issues: #22493: getting linker errors for every nontrivial build on an m1 mac with ghc 9.4.3 · Issues · Glasgow Haskell Compiler / GHC · GitLab and #23668: Configure whether the linker supports gc-sections rather than whether it is GNU linker · Issues · Glasgow Haskell Compiler / GHC · GitLab.

However, to be sure, can you post your Stack config.yaml file’s substantive contents. Delete that, I am pretty sure this is not Stack-related as such, but GHC-related.

#4

The underlying problem is that the Stack-supplied GHC 9.4.7 (which is the one issued by the GHC developers) thinks your system’s linker program supports --gc-sections, but it does not.

Something similar affected GHC 8.4.3 back in 2018: GHC 8.4.3 on macos will generate linker error · Issue #4373 · commercialhaskell/stack · GitHub.

You might try this (even though it is akin to ‘turn it off and on again’): (a) uninstall all Stack with GHCup; (b) delete the Stack root ~/.stack; (c) reinstall Stack, but following the macOS/Apple silicon instructions at Install/upgrade - The Haskell Tool Stack, and the guidance about Xcode Command Line Tools (in case it is something to do with your system’s software development tooling; sometimes macOS updates, but Xcode Command Line Tools do not get updated).

EDIT: I’ve updated your post’s title to be more specific. It may attract more focussed attention.

5 Likes
#5

Here, with Sonoma on a M1, Stack 2.13.1 and 9.6.3 (and all other 9.6 GHCs) from GHCup work.
Just to check if it’s the compiler version or something else on your system

1 Like
#6

I have an M1 and use ghcup to manage my install; I recently switched from GHC 9.4 to using 9.6 for my projects so I concur and recommend upgrading your GHC version as well.

#7

To see if I could reproduce your experience, I’ve upgraded my Mac mini/M1, 2020 from Ventura 13.4.1 to Sonoma 14.1. I could not reproduce your experience (but I am not using GHCup to manage Stack; I use Stack to manage Stack). My output follows (extracts only):

$ stack upgrade --force-download # Ensure I have latest official binary release of Stack
...
$ stack --version
Version 2.13.1, Git revision 8102bb8afce90fc954f48efae38b87f37cabc988 (9949 commits) aarch64 hpack-0.36.0
$ stack new foo
...
$ cd foo
$ stack build
Preparing to install GHC to an isolated location. This will not interfere with any system-level installation.
Downloaded ghc-9.4.7.
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
ld: unknown option: --version
ld: unknown option: --version
Installed GHC.
[1 of 3] Compiling Main ...
...
Registering library for foo-0.1.0.0..
$ stack exec -- which -a ld # What ld is available in Stack environment?
/usr/bin/ld
$ stack exec -- ld -v # What is the version of that ld?
@(#)PROGRAM:ld  PROJECT:ld64-857.1
BUILD 23:13:29 May  7 2023
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 14.0.3, (clang-1403.0.22.14.1) (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 14.0.3 (tapi-1403.0.5.1)

EDIT: Another thing that may be relevant is:

$ which -a clang
/opt/homebrew/opt/llvm@12/bin/clang
/usr/bin/clang
$ clang --version
Homebrew clang version 12.0.1
Target: arm64-apple-darwin23.1.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm@12/bin

I can’t now recall why I have Homebrew’s clang in preference to Apple’s, but I have a vague recollection that, at some point in the past, GHC needed a less-current version of clang than the one Apple provided. (GHC 9.2.8’s manual says it needed LLVM 9 to 12. GHC 9.4.7’s manual says LLVM 10 to 14. GHC 9.6.3’s manual says LLVM 11 to 15, as does GHC 9.8.1’s.)

#8

Dear all,

first of all, thank you very much for your replies. And apologies for taking so long to reply myself, I’ve been too busy travelling :slight_smile:

I have deleted everything that has to do with Haskell in the laptop. Then I have reinstalled ghc via home-brew and then downloaded stack via curl (as suggested above). Another key thing that I did was to delete two of the three versions of clang that were installed on my machine (left the one on /usr/bin). After all these operations, stack works – thank you everyone for suggesting possible solutions.

#9

I use clang/LLVM 17 and have used Apple’s default clang 15 without a problém (so far ;).
So this should not be needed any more.

#10

clang 15 now only and it works. Before there was also v17. No idea if this was the problem - just saying it was one of the operations I performed.

#11

Oh, I didn’t want to express that having more than one version of LLVM (‘specially more than one Homebrew package) doesn’ t cause problems, even if only one of them is set in different environment variables (it does, and it is quite a challenge to get “everything” to use the right clang). Using Apple’s version only is the easiest alternative, as many programs/scripts/build systems… will use it anyway. It’s just not an option if you need a more “standard” Version of LLVM (for example with OpenMP support).

1 Like