Skip to content
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

[WIP] build musl-native instead of cross #3

Closed
wants to merge 14 commits into from

Conversation

dtzWill
Copy link
Contributor

@dtzWill dtzWill commented Jul 13, 2018

Started out wanting to show you how to use nixpkgs + musl, but.....

Anyway I'm new to the nixpkgs haskell packaging infrastructure and I know some of this is going about things the slightly wrong way but seems to work for a few packages at least.

Not all listed here work, but wanted to show you where i ended up!

Feel free to pick+choose bits that you like, definitely don't need to actually "pull" these :).

Hope this helps, GLHF!

@dtzWill
Copy link
Contributor Author

dtzWill commented Jul 13, 2018

Oh, I think some of the problems remaining is for packages that have libraries and executables both, and using wrong linker flags for creating the libraries. Maybe. Heading out for the evening but that might be worth checking-- with justStaticExecutables or so... But not in the overrides since they might be deps. Anyway.

@nh2
Copy link
Owner

nh2 commented Jul 14, 2018

This is so good I am super happy!

Thanks a lot for putting in this effort, this saves me so much time experimenting.

@nh2
Copy link
Owner

nh2 commented Jul 14, 2018

One of the packages that don't build yet, the stack build gives me this (I used stack = appendConfigureFlag (statify super.stack) [ "--ghc-option=-j1" ]; to get deterministic output of what module fails):

[ 44 of 125] Compiling Stack.Constants  ( src/Stack/Constants.hs, dist/build/Stack/Constants.o )
/nix/store/3a74d03pq6d0cg3crkfw965k5s58hbn4-binutils-2.30/bin/ld: /nix/store/rd8w17sgz9wr47nd0s7xvarapib0h9jm-gcc-7.3.0/lib/gcc/x86_64-unknown-linux-musl/7.3.0/crtbeginT.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a shared object
/nix/store/3a74d03pq6d0cg3crkfw965k5s58hbn4-binutils-2.30/bin/ld: /nix/store/rd8w17sgz9wr47nd0s7xvarapib0h9jm-gcc-7.3.0/lib/gcc/x86_64-unknown-linux-musl/7.3.0/crtend.o: relocation R_X86_64_32 against `.ctors' can not be used when making a shared object; recompile with -fPIC
/nix/store/3a74d03pq6d0cg3crkfw965k5s58hbn4-binutils-2.30/bin/ld: final link failed: Nonrepresentable section on output

@nh2 nh2 closed this in f6acf62 Jul 15, 2018
@nh2
Copy link
Owner

nh2 commented Jul 15, 2018

@dtzWill I have squashed the commits, moved the whole thing to the survey directory so we can continue working in there, and added a call for contributions in the README, in commit f6acf62.

@nh2
Copy link
Owner

nh2 commented Jul 18, 2018

@dtzWill

I finally figured out one of the remaining big problem (crtbeginT.o from #3 (comment) above). The problem is where you pass --ghc-option=-optl=-static. It works for many use cases but not for some (e.g. stack or intray-web-server). This is because you intend to pass that flag only to the final gcc/ld invocation that links the exe.

But --ghc-option=-optl=-static will tell GHC to use it for any linker invocation, even those for intermediate files like when TemplateHaskell is used. The solution is to pass that flag only in ghc-options of the executable section in the cabal file instead of as a general GHC option.

And I succeeded building stack 1.7.1 statically this way.

To do this conveniently from nix instead of having to change the package's cabal file, we would need a cabal configure-time flag that does this, e.g. named --enable-static-executables.

Which looks like this cabal feature request: haskell/cabal#391

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants