-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GHC 9.4.5 x86_64, linker error during static build with stack #1
Comments
Cross reference: utdemir/ghc-musl#28 |
Maybe |
@paulcadman See also commercialhaskell/stack#3420 |
Thanks for the suggestion, I get the same linker error with these options. |
Do you have all the required options set according to commercialhaskell/stack#3420 (comment)? |
Not exactly these options, but we have set of options to produce the static builds successfully with GHC 9.2.7 on alpine: https://github.com/anoma/juvix/blob/e0aadef2988d96804b3a65de741c5cbcccc5ab9a/.github/workflows/linux-static-binary.yaml#L38 |
Cross references:
(I assume the latter link is where the Unfortunately, I can not help any further. |
Thanks very much for your help, much appreciated! 🥇 |
@paulcadman Please try with the following: build.sh #!/usr/bin/env sh
set -x
# required to build the juvix runtime
apk add --update clang14
# install stack
curl https://github.com/commercialhaskell/stack/releases/download/v2.11.1/stack-2.11.1-linux-$(uname -m)-static.tar.gz -OL
tar xf stack-2.11.1-linux-$(uname -m)-static.tar.gz
cp stack-2.11.1-linux-$(uname -m)-static/stack /usr/local/bin
# stack permissions bug workaround
chown -R $(id -un):$(id -gn) ~
# clone and build Juvix
git clone --recursive --branch stack-lts-21.6 https://github.com/anoma/juvix.git
cd juvix
make runtime LIBTOOL=llvm14-ar
echo 'ld-options: -static -pthread' >> package.yaml
stack install --allow-different-user --system-ghc --ghc-options='-split-sections' |
For the Linux AArch64 release you need to build a statically linked Cross reference: https://gitlab.haskell.org/ghc/ghc/-/issues/23482 |
More references about building a statically linked binary:
|
Thank you - the combination of options you suggest works! 🎉 |
Please have this reviewed by a GHC expert – I am not one. Regarding
Regarding
(You could append Or should all GHC options go into Ping @TravisCardwell (utdemir/ghc-musl) @mpilgrem (commercialhaskell/stack) |
The options can be pretty confusing, IMHO.
This is what I do.
These should indeed be equivalent.
I do not think that these are equivalent. The GHC
The
The
I think that it is often fine to put such configuration in your BTW, I usually put static build configuration behind a Cabal flag, allowing me to develop easily and then confirm that static builds still work when appropriate (after big changes and before committing). Cabal syntax example: flag static
description: Build static executable
default: False
executable example
...
if flag(static)
ld-options: -static -pthread |
Thank you @TravisCardwell. I tried setting I've used your flags suggestion, the equivalent stack/hpack configuration (in flags:
static:
description: Build static executable
default: false
manual: true
executables:
example:
...
when:
- condition: flag(static)
ld-options:
- -pthread
- -static You then run |
Firstly, thanks for maintaining this project. I wondered if you'd be able to help debug a build issue when using the GHC 9.4.5 container, or suggest something we could try.
We're trying to use ghc-musl to produce static builds for the juvix project but are experiencing a linker issue with the build.
We're using ghc-musl:9.4.5 on x86_64.
The build works with a standard (i.e distributed by GHC) distribution of GHC 9.4.5.
Reproduction steps
stack install --allow-different-user --system-ghc --ghc-options='-static -split-sections -optl-static'
docker run -v $PWD/build.sh:/build.sh --rm -ti glcr.b-data.ch/ghc/ghc-musl:9.4.5 /bin/bash
gzip -d
this is best viewed usingless
because of recorded ANSI escapes).Linker error during build
Upstream issue?
I found this issue which is related https://gitlab.haskell.org/ghc/ghc/-/issues/20168. The solution given there is to configure GHC to use its internal linker (used by ghci). However this does not seem like an ideal solution, we should use the system linker for this (as noted in the GHC documentation, the internal linker has known bugs, and they'd like to remove it).
The text was updated successfully, but these errors were encountered: