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

Jump to bottom

ghc: use system libffi #55208

Merged
merged 1 commit into from Feb 4, 2019
Merged

ghc: use system libffi #55208

merged 1 commit into from Feb 4, 2019

Conversation

guibou
Copy link
Contributor

@guibou guibou commented Feb 4, 2019 •
edited

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.

Motivation for this change

In a nix-shell with haskellPackages.ghcWithPackages(p : [p.bindings-libffi]) using this pull request changes:

$ ghc -dynamic foo.hs  -package bindings-libffi
[1 of 1] Compiling Main             ( foo.hs, foo.o )
Linking foo ...

$ ldd ./foo | grep libffi
        libHSbindings-libffi-0.3-8zlW5dTVIDuCbNJGKO9GeK-ghc8.6.3.so => /nix/store/mblpjxlcyklsfwpa9n7bx2rsxazv2bpb-bindings-libffi-0.3/lib/ghc-8.6.3/x86_64-linux-ghc-8.6.3/libHSbindings-libffi-0.3-8zlW5dTVIDuCbNJGKO9GeK-ghc8.6.3.so (0x00007f2ca2203000)
        libffi.so.6 => /nix/store/ddgaziqy9m2jgm4z8dzkhqd3w9hzryns-libffi-3.2.1/lib/libffi.so.6 (0x00007f2ca06e6000)

Hovever, in a similar nix-shell, without this commit:

$ ghc -dynamic foo.hs  -package bindings-libffi
[1 of 1] Compiling Main             ( foo.hs, foo.o )
Linking foo ...
/nix/store/3xwc1ip20b0p68sxqbjjll0va4pv5hbv-binutils-2.30/bin/ld: warning: libffi.so.7, needed by /nix/store/cclv7n6jr311i5ywwkms1m3iz4lsg37j-ghc-8.6.3/lib/ghc-8.6.3/rts/libHSrts-ghc8.6.3.so, may conflict with libffi.so.6
/nix/store/3xwc1ip20b0p68sxqbjjll0va4pv5hbv-binutils-2.30/bin/ld: warning: libffi.so.7, needed by /nix/store/cclv7n6jr311i5ywwkms1m3iz4lsg37j-ghc-8.6.3/lib/ghc-8.6.3/rts/libHSrts-ghc8.6.3.so, may conflict with libffi.so.6

$ ldd ./foo | grep libffi
        libHSbindings-libffi-0.3-8zlW5dTVIDuCbNJGKO9GeK-ghc8.6.3.so => /nix/store/nbn5p1zs45ynhdjanjmc7hn8g5pvn064-bindings-libffi-0.3/lib/ghc-8.6.3/x86_64-linux-ghc-8.6.3/libHSbindings-libffi-0.3-8zlW5dTVIDuCbNJGKO9GeK-ghc8.6.3.so (0x00007eff1f4b9000)
        libffi.so.6 => /nix/store/qwmw5ddw8lk2pz4fy3irp87vj1cawvjh-libffi-3.2.1/lib/libffi.so.6 (0x00007eff1d99c000)
        libffi.so.7 => /nix/store/cclv7n6jr311i5ywwkms1m3iz4lsg37j-ghc-8.6.3/lib/ghc-8.6.3/rts/libffi.so.7 (0x00007eff1cb20000)

Observes the warnings during linking and the two libffi which appears when calling ldd.

Discussion

  • haskell full static build now depends on the availablility of static version of 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 until libffi comes with static libraries? I've just pushed libffi: enable static build #55207 for that matter. edit Actually libffi comes with a static configuration, so this may not be a problem.
  • version bump of libffi will triggers a mass rebuild of ghc and all haskell packages.
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@guibou
ghc: use system libffi
33fefc7 
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`.
@peti peti changed the base branch from master to haskell-updates February 4, 2019 16:46
@peti
Copy link
Member

peti commented Feb 4, 2019

I re-targeted the patch to haskell-updates.

@guibou
Copy link
Contributor Author

guibou commented Feb 4, 2019

@peti: for my culture, what is the purpose of this branch? Minimising mass rebuild of haskell packages by grouping together merges to master?

@peti
Copy link
Member

peti commented Feb 4, 2019

The branch is for integration testing. We build significant changes in haskell-updates before merging them to master. Current build results are at https://hydra.nixos.org/jobset/nixpkgs/haskell-updates.

@peti peti force-pushed the haskell-updates branch 2 times, most recently from 14488df to 0f68f39 Compare February 4, 2019 17:11
@peti peti merged commit 9134c02 into NixOS:haskell-updates Feb 4, 2019
@guibou guibou deleted the ghc_no_libffi branch February 4, 2019 19:20
@guibou
Copy link
Contributor Author

guibou commented Feb 4, 2019

@peti Naive question, and perhaps a bit late.

I upgraded ghc-8.6.3 nix file, because that's the GHC currently used. Should we also upgrade others ghc? Especially HEAD version. How do I ensure that this fix will appear in the nix file for future ghc version?

@peti
Copy link
Member

peti commented Feb 4, 2019 via email

@guibou
Copy link
Contributor Author

guibou commented Feb 4, 2019

@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 libffi because of build issues with libffi-3.2 (the one in nixpkgs). See discussion here: libffi/libffi#296

Some distributions (such as debian testing) are packaging libffi-3.3rc0. The release is schedule since a long time, but nothing happened.

@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?

peti pushed a commit that referenced this pull request Feb 7, 2019
@guibou @peti
ghc-8.6.3: use system libffi
8e74189 
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.
peti pushed a commit that referenced this pull request Feb 11, 2019
@guibou @peti
ghc-8.6.3: use system libffi
ad7fc56 
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.
peti pushed a commit that referenced this pull request Feb 12, 2019
@guibou @peti
ghc-8.6.3: use system libffi
a7c7743 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@basvandijk basvandijk Awaiting requested review from basvandijk

@peti peti Awaiting requested review from peti

@ryantm ryantm Awaiting requested review from ryantm

@kosmikus kosmikus Awaiting requested review from kosmikus

Assignees
No one assigned
Labels
6.topic: haskell 10.rebuild-darwin: 501+ 10.rebuild-darwin: 5001+ 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@guibou @peti @GrahamcOfBorg