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: Add enableBootLibPIC option. #29829
Conversation
7020dc0
to
05025d5
Compare
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.
This seems like such a niche use-case that I don't want to support it in Nixpkgs, really, especially considering the fact that the patches are so long and repetitive and error-prone. IMHO, users who want this feature should implement it in their local setup by way of override
. Also, I don't believe that we would ever offer a binary cache for any package sets with that feature enabled.
Hmm, it seems there are fewer people building libraries this way than I
thought. This is really handy in a commercial setting where it's often
necessary to deliver Haskell code to another team working in a different
language, or that needs to be called from a larger system.
Perhaps you'd consider a function like ghcWithPICPackages; right now only
Stack makes it reasonably easy to build a package with specific GHC options
set on the whole transitive dependency closure (except for the wired-in
packages, hence the need for something like what's proposed here). It's not
clear to me how to write such a thing, since (as far as I understand)
ghc-pkg can't be used to swap out builtin_rts or ghc-prim.
Maybe GHC itself would consider making it possible to build this way with a
single option set in build.mk, and perhaps that would make it more
palatable to add such an option to these derivations.
…On Wed, Sep 27, 2017 at 1:24 AM Peter Simons ***@***.***> wrote:
***@***.**** commented on this pull request.
This seems like such a niche use-case that I don't want to support it in
Nixpkgs, really, especially considering the fact that the patches are so
long and repetitive and error-prone. IMHO, users who want this feature
should implement it in their local setup by way of override. Also, I
don't believe that we would ever offer a binary cache for any package sets
with that feature enabled.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#29829 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABP-u4RiG8FEln6gl_YwOqPPZqiC9Zcsks5smfgQgaJpZM4PlHSC>
.
|
It seems it is possible to get GHC to link against a different set of wired-in packages by simply using the right If there's no interest in supporting position independent code at all, perhaps it would at least be acceptable to refactor these derivations to make it easier to do the requisite override. Each GHC derivation is factored slightly differently; some define |
05025d5
to
a5f8b15
Compare
a5f8b15
to
8c255b5
Compare
GHC derivations now have |
Motivation for this change
This adds an option called
enableBootLibPIC
to the non-binary GHC derivations. This option simply builds the GHC boot libraries with-fPIC
. Providing position-independent boot libraries allows one to easily build Haskell code into shared objects that are statically linked against all Haskell dependencies, including the RTS. This is not possible with the default GHC build. This is principally desirable when providing Haskell libraries that are meant to be called from foreign code, since the calling code's linking process doesn't have to know anything about GHC at all.This may be a rather niche use case, although it would be nice to add GHCs with this option set true to the binary cache.
Things done
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)