haskell-stack conflicts with llvm

[Baltoli]

brew gist-logs <formula> link OR brew config AND brew doctor output

HOMEBREW_VERSION: 3.6.20
ORIGIN: https://github.com/Homebrew/brew
HEAD: 344d32bf7f40183359592ef81ca6486e0587981b
Last commit: 3 weeks ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 5e1f270eaee16a968bc5dfc39398281976c1ea3b
Core tap last commit: 4 days ago
Core tap branch: master
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: ["--no-quarantine"]
HOMEBREW_CLEANUP_PERIODIC_FULL_DAYS: 3650
HOMEBREW_COLOR: set
HOMEBREW_MAKE_JOBS: 3
HOMEBREW_NO_AUTO_UPDATE: set
Homebrew Ruby: 2.6.8 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8_1/bin/ruby
CPU: 3-core 64-bit ivybridge
Clang: 13.0.0 build 1300
Git: 2.39.1 => /usr/local/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.7.3-x86_64
CLT: 13.2.0.0.1.1638488800
Xcode: 13.2.1 => /Applications/Xcode_13.2.1.app/Contents/Developer
Your system is ready to brew.

Verification

• My "brew doctor output" says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.

What were you trying to do (and why)?

We have a formula in a non-core tap that depends on both haskell-stack and llvm to build different components of a larger application; the problem manifests when trying to build the formula in our regular CI workflow.

What happened (include all command output)?

A recent upgrade of the GHC version in our Stack resolver seems to have triggered a known failure mode in GHC / stack, where an LLVM installation on the system path conflicts with what stack expects to find, generating obscure linker errors:

The GHC located at /private/tmp/kframework-20230207-8192-r85p71/kframework-5.5.85/.brew_home/.stack/programs/x86_64-osx/ghc-9.2.5/bin/ghc-9.2.5 failed to compile a sanity check. Please see:

    http://docs.haskellstack.org/en/stable/install_and_upgrade/

for more information. Exception was:
Received ExitFailure 1 when running
Raw command: /private/tmp/kframework-20230207-8192-r85p71/kframework-5.5.85/.brew_home/.stack/programs/x86_64-osx/ghc-9.2.5/bin/ghc-9.2.5 /private/tmp/stack-sanity-check-97f115f2930484a2/Main.hs -no-user-package-db
Run from: /private/tmp/stack-sanity-check-97f115f2930484a2/
Standard output:

[1 of 1] Compiling Main             ( /private/tmp/stack-sanity-check-97f115f2930484a2/Main.hs, /private/tmp/stack-sanity-check-97f115f2930484a2/Main.o )
Linking /private/tmp/stack-sanity-check-97f115f2930484a2/Main ...
Standard error:

clang: warning: -Wl,-headerpad_max_install_names: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/usr/local/opt/bison/lib' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/usr/local/opt/flex/lib' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/usr/local/opt/llvm@13/lib' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/usr/local/opt/icu4c/lib' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/usr/local/lib' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries' [-Wunused-command-line-argument]
ld64.lld: error: unknown argument '--gc-sections'
ld64.lld: error: BRANCH relocation has width 1 bytes, but must be 4 bytes at offset 15 of __TEXT,__text in /private/tmp/kframework-20230207-8192-r85p71/kframework-5.5.85/.brew_home/.stack/programs/x86_64-osx/ghc-9.2.5/lib/ghc-9.2.5/lib/../lib/x86_64-osx-ghc-9.2.5/ghc-bignum-1.2/libHSghc-bignum-1.2.a(add_n.o)
ld64.lld: error: BRANCH relocation has width 1 bytes, but must be 4 bytes at offset 15 of __TEXT,__text in /private/tmp/kframework-20230207-8192-r85p71/kframework-5.5.85/.brew_home/.stack/programs/x86_64-osx/ghc-9.2.5/lib/ghc-9.2.5/lib/../lib/x86_64-osx-ghc-9.2.5/ghc-bignum-1.2/libHSghc-bignum-1.2.a(sub_n.o)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`clang' failed in phase `Linker'. (Exit code: 1)

This is a known issue for several stack versions, but it's not clear to us why it's only started happening with this upgrade to stack.

What did you expect to happen?

The stack setup command should succeed.

Step-by-step reproduction instructions (by running brew commands)

Repo with demonstration: https://github.com/Baltoli/homebrew-issue

The reproduction for this issue is a bit tricky; I haven't been able to get it to reproduce on my local machine (owing to previous brew or stack installations cluttering up whatever PATH stack is looking at), so I have set up a demo repository that exhibits the problem in a minimal formula.

This repo contains a formula depending on haskell-stack and (optionally) LLVM. I have set up Github actions to build the problematic formula with and without the optional LLVM dependency, demonstrating the same error message we have been experiencing. The brew environment on these runners is not totally fresh (there's a few packages preinstalled), but brew doctor reports it's ready to brew.

In case the logs aren't visible (this run is the interesting one), the repro. boils down to observing that for the linked formula, this command succeeds:

brew install ./Formula/demo.rb

while this fails:

brew install ./Formula/demo.rb --with-llvm

Please let me know if I can improve the format of this reproduction at all.

I suspect that the general solution for this is a conflicts_with marker for these packages, but I'd be grateful to know if there is any way to cut the LLVM-installed PATH entries out when running stack setup, and reinstate them for the rest of the build. Nothing jumped out at me from the API docs (perhaps reasonably).

[Baltoli]

For what it's worth, I did a trivial grep through the Formula directory of Homebrew core and I'm pretty sure this problem is unique (might exist in another tap somewhere I guess): runtimeverification/k#3145 (comment)

[Baltoli]

I note also that with this dance I can successfully build the minimal example:

old_path = ENV["PATH"]

ENV["PATH"] = ENV["PATH"].sub "#{Formula["llvm"].bin}:", ""
system "stack", "setup"
ENV["PATH"] = old_path

Is there any way to make this hack a bit cleaner?

[alebcay]

I can't speak to this being the correct permanent solution, but your hack could be made a bit cleaner using with_env, e.g.:

with_env(PATH: ENV["PATH"].sub("#{Formula["llvm"].bin}:", "")) do
  system "stack", "setup"
end

This could possibly be golfed down more but it should help with at least the scoping aspect.

[carlocab]

This looks suspicious:

ld64.lld: error: unknown argument '--gc-sections'

Does stack/ghc pass -fuse-ld=lld to clang during compilation?

[carlocab]

Yes, it looks like stack does use -fuse-ld=lld for some reason, but presumably only if it can find lld in PATH. commercialhaskell/stack#4373

I believe this makes it mistakenly assume it's using GNU ld (because ld.lld is GNU ld-compatible), which results in passing arguments that ld64 doesn't recognise.

[carlocab]

Just a guess, but doing

ENV["LD"] = "ld"

might work.

[carlocab]

I think this is fixed upstream in GHC. Unfortunately, the fix isn't due until GHC 9.6.

In the meantime, stack can probably fix this by passing --disable-ld-override when configuring the GHC toolchain that it downloads. I'm not familiar enough with stack to know if it's possible for you to tell stack to do this, but I'm guessing it should be.

Alternatively, you can use a Homebrew-built GHC which (probably) shouldn't be affected by this problem. (Pass --system-ghc and --no-install-ghc to stack.)

Given this, I'm relatively confident that this is a bug in stack, and should be fixed there. (Open to evidence of the contrary, however.) But, if this is the case, then there's not much actionable for us here.

There isn't really a conflict between haskell-stack and llvm in the sense used by other formulae, since declaring conflicts_with just makes it difficult for users to have both installed at the same time. Not to mention that M1 users actually do need llvm@12 installed to use GHC, and that having an LLVM formula installed when using haskell-stack presents problems only when llvm@* is added to PATH.

[Baltoli]

Thanks all, that's really helpful advice. I suspect the best thing for us to do is keep some version of the scoped ENV hack for now until the fix reaches our stack resolver via upstream GHC. Will close this issue as it's upstream of homebrew.