-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
haskell: pkgsStatic fixes #162374
haskell: pkgsStatic fixes #162374
Conversation
|
I see your point, though I'm not sure how useful the default compiler is, given most packages fails to build. Ideally, we should fix the linking errors, but avoiding gmp is the only way I've found so far.
Done. |
GhcLibHcOpts += -fPIC -fexternal-dynamic-refs | ||
GhcRtsHcOpts += -fPIC -fexternal-dynamic-refs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you be able to add a comment here why -fexternal-dynamic-refs
is needed for enableRelocatedStaticLibs
?
From the GHC manual: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/phases.html#ghc-flag--fexternal-dynamic-refs
When generating code, assume that entities imported from a different module might be dynamically linked. This flag is enabled automatically by -dynamic.
It is not clear to me why this would be necessary if we are statically linking things. (Although I don't have a good understanding of static linking, so maybe it should be obvious.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to admit I'm baffled by this too and was kind of expecting the haskell maintainers would know better.
Basically, I'm implementing the solution proposed in this blog post: https://www.tweag.io/blog/2020-09-30-bazel-static-haskell/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the link to the blog post. It says:
When evaluating template Haskell splices, GHC will execute compiled expressions in its built-in bytecode interpreter and this code has to be compatible with the RTS of GHC itself. In short, a GHC configured with a dynamic RTS will not be able to load static Haskell libraries to evaluate template Haskell splices.
It then goes on to say:
We need to build GHC with a static RTS and to make sure that Haskell code is compiled as position independent code so that it can be loaded into a running GHC for template Haskell splices.
Both of these statements make sense of course, but they don't seem to explain why -fexternal-dynamic-refs
is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The GHC man page reads:
Generate code for linking against dynamic libraries
I assume this means that the RTS will have some kind of dynamic library loading facilities even of static (Haskell?) archives, so the byte code interpreter / whatever used by TH will actually work. -fPIC
also serves this purpose.
Maybe I'm misinterpreting, but it seems that this change allows building Haskell packages from |
Yes, correct. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the above comment suggestions, this LGTM!
I tried nix-build -A pkgsStatic.pretty-simple
and it appears to build and run correctly!
@sternenseemann Does this look alright to merge to you? |
Have you tried actually building anything that uses FFI in TH? I guess that would need a dynamically linked library as well? I'm still opposed to changing the meaning of haskellPackages = dontRecurseIntoAttrs (
if stdenv.hostPlatform.isStatic
then haskell.packages.native-bignum.ghc902
else haskell.packages.ghc902
);
/* … */
ghc = targetPackages.haskellPackages.ghc or (
if stdenv.targetPlatform.isStatic
then haskell.compiler.native-bignum.ghc902
else haskell.compiler.ghc902
);
|
Looks great to me! Thanks for the suggestion. |
I agree this was a good suggestion. I think the current state of this PR makes a lot of sense, having
That's a good question. Do you happen to know a package that uses FFI in TH off the top of your head? I gave it some thought, but I couldn't come up with anything. (I did try compiling Although even if this doesn't work, I don't feel like it should hold up merging this PR, since this PR currently improves the status quo. |
So, can we merge this? |
Probably, I'll try to have a final look soon. A small request: Could you use |
Commit message updated and rebased. |
This change allows loading statically compiled libreries into a running GHC, thus fixing the build of haskell packages that use TemplateHaskell. See [1] for the details. Fixes issue NixOS#61575, NixOS#124284. [1]: https://www.tweag.io/blog/2020-09-30-bazel-static-haskell/
adb4686
to
708ae5b
Compare
This change makes the haskell builder run the haddockPhase only if the haddock program is availble (for example, it's not when cross-compiling).
This works around several build failures where programs attempt to link to the libgmp.so (which is not available), such as: Error loading shared library libgmp.so: No such file or directory
708ae5b
to
a503a02
Compare
@sternenseemann Thank you for reviewing! |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/statically-linking-haskell-fails-to-link-libffi/18317/2 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/statically-linking-haskell-fails-to-link-libffi/18317/3 |
Motivation for this change
Fixing common build failures in pkgsStatic.haskellPackages
See the commit messages for details.
Things done
pkgsStatic.haskellPackages.{QuickCheck,pretty-simple}
(previously failing)pkgsStatic.haskellPackages.pandoc