-
-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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: use system libffi
#55208
ghc: use system libffi
#55208
Conversation
Use the system `libffi` (`ie` nixpkgs's) instead of built-in libffi from ghc source tree. This will prevent library conflict when ghc dynamically links haskell packages (linked with ghc built-in libffi) and any external library which uses nixpkgs `libffi`.
I re-targeted the patch to |
@peti: for my culture, what is the purpose of this branch? Minimising mass rebuild of haskell packages by grouping together merges to master? |
The branch is for integration testing. We build significant changes in |
14488df
to
0f68f39
Compare
@peti Naive question, and perhaps a bit late. I upgraded |
If you have the time to add the same feature to the other compilers too, then that would be great. HEAD would definitely benefit from having that patch. The most important one is the 8.6.3 build though, which has the patch already.
|
@peti OK. I'll port this work on others GHC versions soon. However I'm starting to be afraid and I wonder if I had not done a mistake. @angerman forced ghc to use an internal copy of Some distributions (such as debian testing) are packaging @angerman, I'm having issues understanding what I may have broke with this change. Is that a specific setup not handled by nixpkgs yet, or on an unreleased version of ghc, or did I broke something important? |
Use the system `libffi` (`ie` nixpkgs's) instead of built-in libffi from ghc source tree. This will prevent library conflict when ghc dynamically links haskell packages (linked with ghc built-in libffi) and any external library which uses nixpkgs `libffi`. Closes #55208.
Use the system `libffi` (`ie` nixpkgs's) instead of built-in libffi from ghc source tree. This will prevent library conflict when ghc dynamically links haskell packages (linked with ghc built-in libffi) and any external library which uses nixpkgs `libffi`. Closes #55208.
Use the system `libffi` (`ie` nixpkgs's) instead of built-in libffi from ghc source tree. This will prevent library conflict when ghc dynamically links haskell packages (linked with ghc built-in libffi) and any external library which uses nixpkgs `libffi`. Closes #55208.
Use the system
libffi
(ie
nixpkgs's) instead of built-in libffifrom ghc source tree.
This will prevent library conflict when ghc dynamically links haskell
packages (linked with ghc built-in libffi) and any external library
which uses nixpkgs
libffi
.Motivation for this change
In a
nix-shell
withhaskellPackages.ghcWithPackages(p : [p.bindings-libffi])
using this pull request changes:Hovever, in a similar
nix-shell
, without this commit:Observes the warnings during linking and the two
libffi
which appears when callingldd
.Discussion
libffi
, which is not the case in nixpkgs. This will be an issue, see Fully static Haskell executables - overview issue #43795. Should this PR be blocked untillibffi
comes with static libraries? I've just pushed libffi: enable static build #55207 for that matter. edit Actuallylibffi
comes with a static configuration, so this may not be a problem.libffi
will triggers a mass rebuild of ghc and all haskell packages.Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)