Dynamic executables built by Stack on a macOS/AArch64 system segfault #6386
Comments
|
@mouse07410, is this a regression compared to earlier versions of Stack? I am thinking of your issue #5199. |
|
Yes it is - because back then it built executables successfully, and the problem was installing dynamic libraries into the right places (which stack failed to do). Now it can't even build them, creating I haven't been using stack for years, but am trying to maintain a working setup just in case, so decided to test it - and reported the problem. I'm pretty sure one of the earlier versions of stack could do least do |
|
@mouse07410, on WSL2 (Ubuntu 22.04.3 LTS), with a simple 'toy' one-package project resolver: lts-22.0
configure-options:
$targets:
- --enable-executable-dynamicmaking use of https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-flag---enable-executable-dynamic. That seemed to work - everything built and the executable was much smaller than the one built without specifying that Cabal configuration option. |
|
@mpilgrem very interesting. I copied your excerpt into $ stack build
h-stack-tst1-0.1.0.0: unregistering (local file changes: CHANGELOG.md README.md app/Main.hs
h-stack-tst1.cabal package.yaml src/Lib.hs)
Building all executables for h-stack-tst1 once. After a successful build of all of them, only specified
executables will be rebuilt.
h-stack-tst1> configure (lib + exe)
Configuring h-stack-tst1-0.1.0.0...
h-stack-tst1> build (lib + exe)
Preprocessing library for h-stack-tst1-0.1.0.0..
Building library for h-stack-tst1-0.1.0.0..
[1 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/aarch64-osx/ghc-9.6.3/build/Lib.o, .stack-work/dist/aarch64-osx/ghc-9.6.3/build/Lib.dyn_o )
[2 of 2] Compiling Paths_h_stack_tst1 ( .stack-work/dist/aarch64-osx/ghc-9.6.3/build/autogen/Paths_h_stack_tst1.hs, .stack-work/dist/aarch64-osx/ghc-9.6.3/build/Paths_h_stack_tst1.o, .stack-work/dist/aarch64-osx/ghc-9.6.3/build/Paths_h_stack_tst1.dyn_o )
ld: warning: -single_module is obsolete
Preprocessing executable 'h-stack-tst1-exe' for h-stack-tst1-0.1.0.0..
Building executable 'h-stack-tst1-exe' for h-stack-tst1-0.1.0.0..
[1 of 2] Compiling Main ( app/Main.hs, .stack-work/dist/aarch64-osx/ghc-9.6.3/build/h-stack-tst1-exe/h-stack-tst1-exe-tmp/Main.dyn_o )
[2 of 2] Compiling Paths_h_stack_tst1 ( .stack-work/dist/aarch64-osx/ghc-9.6.3/build/h-stack-tst1-exe/autogen/Paths_h_stack_tst1.hs, .stack-work/dist/aarch64-osx/ghc-9.6.3/build/h-stack-tst1-exe/h-stack-tst1-exe-tmp/Paths_h_stack_tst1.dyn_o )
[3 of 3] Linking .stack-work/dist/aarch64-osx/ghc-9.6.3/build/h-stack-tst1-exe/h-stack-tst1-exe
ld: warning: ignoring duplicate libraries: '-lm'
h-stack-tst1> copy/register
Installing library in /Users/ur20980/src/h-stack-tst1/.stack-work/install/aarch64-osx/89d39da80602756ab996a9b78727e7b07dd4e0adde41b5ea60d940c51b3160ca/9.6.3/lib/aarch64-osx-ghc-9.6.3/h-stack-tst1-0.1.0.0-HLOUcWGFe3L9flc5gzPiOW
Installing executable h-stack-tst1-exe in /Users/ur20980/src/h-stack-tst1/.stack-work/install/aarch64-osx/89d39da80602756ab996a9b78727e7b07dd4e0adde41b5ea60d940c51b3160ca/9.6.3/bin
Registering library for h-stack-tst1-0.1.0.0..
$ otool -L /Users/ur20980/src/h-stack-tst1/.stack-work/install/aarch64-osx/89d39da80602756ab996a9b78727e7b07dd4e0adde41b5ea60d940c51b3160ca/9.6.3/bin/h-stack-tst1-exe
/Users/ur20980/src/h-stack-tst1/.stack-work/install/aarch64-osx/89d39da80602756ab996a9b78727e7b07dd4e0adde41b5ea60d940c51b3160ca/9.6.3/bin/h-stack-tst1-exe:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
@rpath/libHSh-stack-tst1-0.1.0.0-HLOUcWGFe3L9flc5gzPiOW-ghc9.6.3.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSbase-4.18.1.0-ghc9.6.3.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-bignum-1.3-ghc9.6.3.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-prim-0.10.0-ghc9.6.3.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSrts-1.0.2_thr-ghc9.6.3.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/opt/local/lib/libffi.8.dylib (compatibility version 10.0.0, current version 10.2.0)
$ stack run
zsh: segmentation fault stack run
$ Attempt to debug gave this: From the crash report: |
|
@mouse07410, I have access to a Mac mini M1 2020, with macOS 14.1/AArch64. I can't reproduce your problem; for me, macOS behaves the same way as Ubuntu and Compared to my experience, you are getting linker errors: On my system, in case it is relevant: My
which looks very similar to your output, save for EDIT2: Perhaps this past Stack issue is relevant: #1826 |
mpilgrem
changed the title
|
Interesting. Very interesting. I'm now at 14.2.1 too. Xcode-15.1. Most of the packages (such as GCC-13, etc.) that don't come with the OS itself, are installed via MacPorts. Unfortunately, MacPorts has its own versions of ``libiconv How, Haskell (GHC, Cabal, your Stack, etc.) binary distributions rely upon the MacOS (or, rather, XCode) versions of those libraries. Which means: in Haskell software that needs to use or depend on, e.g., OpenSSL, I have to link it with the above MacOS libraries first, then with the relevant MacPorts libraries - and then with the rest of the MacOS libraries. It's crazy - I know, but that's the only way I found for "it" to work. After ensuring that When I added resolver: lts-22.0
configure-options:
$targets:
- --enable-executable-dynamicto the project's Here's the crash report: And a similar crash on M2 MacOS 14.2.1: with crash: |
|
Removing |
|
For completeness, there are GHC issues which seems to have something to do with the |
|
And, again, somehow Cabal doesn't seem to manifest this problem: Any idea what Stack is doing differently here??? |
|
@mouse07410, so we are comparing like for like, what does Cabal (the tool) do with GHC 9.6.3? We can see the Cabal commands that Stack is relying on with |
|
Sure. Here's the log (output of For comparison, output of |
|
@mouse07410, I don't know if it has any significance, but I've spotted these differences in terms of the output from Stack:
|
I wonder - you're passing it through Stack, right?I tried to find a way to pass it via
Yes I do. They don't seem to hurt, except for
True, I do... But the referred libraries seem to all be either in the Haskell/GHC land, or in the MacOS/Xcode land... They would be needed for real projects, but not for this toy one... I think the following proves that these are harmless. And now, the solution, or at least pinpointing of the culprit. It is Current ghc-options:
# All packages
"$locals": -Wall #-dynamic
"$targets": -Wall #-dynamic
#"$targets": -Werror -dynamic
"$everything": -Wall -O2 -fPIC -haddock # -flink-rts
#apply-ghc-options: locals
#apply-ghc-options: targets
apply-ghc-options: everythingCurrent resolver: lts-22.0
configure-options:
$targets:
- --enable-executable-dynamicAnd the result: One definite problem discovered is: with Another possible problem that I see - something's wrong with Oh, and of course, the above works with and applies to GHC-9.8.1 too. |
|
@mouse07410, you can specify non-project specific options in either a project's YAML configuration file ( configure-options:
$targets:
- --enable-executable-dynamicFor completeness, I'll record here some of the flags/options that are being passed to GHC with
I do not know if a user can replicate that complexity by bypassing Cabal (the library) and just passing flags directly from Stack to GHC (via Cabal (the library)). Also for completeness, I'll post here my analysis of what |
|
I've added something to Stack's online documentation. |
|
Funny. I'm pretty sure I tried what you suggested earlier and it didn't work - but I tried it again now, and it worked perfectly. Perhaps I forgot to do Summary: configure-options:
$targets:
- --enable-executable-dynamicin ghc-options:
# All packages
"$locals": -Wall #-dynamic
"$targets": -Wall #-dynamic
#"$targets": -Werror #-dynamic
"$everything": -Wall -O2 -fPIC -haddock # -dynamic # -flink-rts
apply-ghc-options: everythingdo not interfere with the above Tested on MacOS Sonoma x86_64 and aarch64, with GHC-9.6.3 and 9.8.1. Thank you! |
General summary/comments (optional)
Stack 2.13.1 fails to compile and link dynamic executables.
To be more specific, it compiles source
.hsfiles to.o, while the linker expects.dyn_o- which causes "File not found error" and linker abort.Why it matters
Statically linked on x86_64:
Statically linked on AARCH64:
$ ll /Users/ur20980/src/hsk-stack-tst1/.stack-work/install/aarch64-osx/89d39da80602756ab996a9b78727e7b07dd4e0adde41b5ea60d940c51b3160ca/9.6.3/bin total 22656 drwxr-xr-x 3 ur20980 staff 96 Dec 16 19:15 ./ drwxr-xr-x 6 ur20980 staff 192 Dec 16 19:15 ../ -rwxr-xr-x 1 ur20980 staff 11598672 Dec 16 19:15 hsk-stack-tst1-exe*Dynamically linked (with Cabal) on x86_64:
Dynamically linked (with Cabal) on AARCH64:
$ ll /Users/ur20980/src/hsk-stack-tst1/dist-newstyle/build/aarch64-osx/ghc-9.8.1/hsk-stack-tst1-0.1.0.0/x/hsk-stack-tst1-exe/opt/build/hsk-stack-tst1-exe/hsk-stack-tst1-exe -rwxr-xr-x 1 ur20980 staff 100160 Dec 16 19:16 /Users/ur20980/src/hsk-stack-tst1/dist-newstyle/build/aarch64-osx/ghc-9.8.1/hsk-stack-tst1-0.1.0.0/x/hsk-stack-tst1-exe/opt/build/hsk-stack-tst1-exe/hsk-stack-tst1-exe* $Observe two orders of magnitude size increase against Cabal-built binaries.
Steps to reproduce
-dynamicis present inghc-options:in~/.stack/config.yaml(see below)stack new hsk-stack-tst1cd hsk-stack-tst1stack buildstack.yaml:Relevant part from
~/.stack/config.yaml:Expected
Here's what's happening when I remove
-dynamicfrom theghc-optionsin~/.stack/config.yaml:Actual
Stack version
Method of installation
Platform
MacOS Sonoma 14.2, multiple versions of GHC (9.2.8, 9.4.8, 9.6.3, 9.8.1) - everything installed via GHCup.
The text was updated successfully, but these errors were encountered: