Coupled with limitations of build system in leads to bug #411789
Also causes problems with portage-2.2 @preserved-libs: ghc will always depend on libffi.so.5, and @preserved-libs doesn't know that this will likely be satisfied by /usr/lib64/ghc-7.4.1/libffi.so.5, so it refuses to unmerge the preserved /usr/lib64/libffi.so.5.
Created attachment 309949 [details, diff] Patch v2 The upstream ticket mentioned in the URL references a patch which apparently is used by both Debian and Fedora. That patch (let's call it v1) wasn't enough for me: the build complained about ffi.h not being found. Apparently other distros install that header in some global place, whereas Gentoo installs it into the strange location of /usr/lib64/libffi-3.0.11/include . The best way to find that location is probably using pkg-config. So I added two more hunks to pass the output of "pkg-config --cflags-only-I libffi" to the relevant compiler invocations. I did so in a fairly minimalistic way, only affecting those command lines which need it. There might be a way to set this more easily for the whole build process, but as their build process is fairly non-standard, I didn't feel like searching for alternatives once I found one viable solution. I'm attaching the resulting patch, v2. Note that the common approach of "ebuild prepare + patch + ebuild merge" won't work for ghc, as the unpack phase will change the timestamp of the WORKDIR, causing the second run to recreate the WORKDIR, replacing the patched tree. If you as a user want to apply the patch that way, touch the WORKDIR in between. As one alternative, you could copy the ebuild to an overlay. As another alternative, you could wait till the main portage tree receives a revbump with that patch (or some version of it) included. If devs were to add a call to epatch_user, such problems would be a lot simpler to address in the future.
The patch looks good. Thank you! Pushed to overlay for now: https://github.com/gentoo-haskell/gentoo-haskell/commit/2745ae0c699bab3bdf83fc2b3ba6903005ebc7b4 Does it also add libffi include path to generated /usr/lib/ghc-7.4.1/package.conf.d/builtin_rts.conf ? I'm afraid failure to do so will render in nonworking stub generator for unreg arches.
(In reply to comment #3) > Does it also add libffi include path to generated builtin_rts.conf? No. It does add ffi to extra-libs, but nothing for include-dirs. There is already a hunk adding that line, but transporting the required information from the build system into the text substitution for that file might be nontrivial.
OK. Pushed Martin's patch as is. >*ghc-7.4.1-r1 (27 Apr 2012) > > 27 Apr 2012; Sergei Trofimovich <slyfox@gentoo.org> > +files/ghc-7.4.2-system-libffi.patch, +ghc-7.4.1-r1.ebuild: > Switched to using system's libffi. Thanks for the fix to Martin von Gagern > (bug #411925). Added new variable to override disabled parallel build: > 'I_DEMAND_MY_CORES_LOADED' (Brave Hearts only). Thank you, Martin! I'll close the bug once: - test on some unreg arches - and add libffi/libgmp as backup libraries for binary ghc builds (only bootstrap binaries).
OK, the patch has a deficiency: rts.conf does not store libffi includepaths in it. It leads to build breakage on unreg platforms.
As I don't have a good idea of what you mean by "unreg arches", I don't feel like I can contribute here. Can you improve on my patch on a system where you can test those improvements?
Initial fix was handled upstream: https://ghc.haskell.org/trac/ghc/ticket/5743 Unregisterised (./configure --enable-unregisterised) arches were fixed in: https://ghc.haskell.org/trac/ghc/ticket/8748
