Including libffi as a submodule

Hello everyone, As you may know, GHC carries a dependency on the libffi library. Libffi is used on most platforms (notably not x86 and x86-64) for foreign function invocation (see rts/Adjustor.c for details). While libffi works well, it is unfortunately not particularly actively maintained. In fact, it has been nearly three years since the last official release. A lot can happen in three years and there is now at least two bugs [1,2] present in the current release which makes it impossible to build GHC in some configurations. These bugs have been fixed upstream but these fixes are unreleased. Numerous attempts have been made to get the libffi maintainers to cut a new release but sadly no progress has been made in over six months of trying. In light of this I propose that we begin treating libffi as a submodule until a release is made. In particular, adding libffi as a submodule will ease development on ARM and AArch64 (especially Apple) targets, which have seen quite a bit of developer attention recently. Note that under this scheme it will still be possible to link against the system's libffi installation using ./configure's --enable-system-libffi flag. Are there any strong objections to plan? If so please speak up. If there is no objection by Saturday we will move ahead. Cheers, - Ben [1] https://github.com/libffi/libffi/issues/191 [2] https://github.com/libffi/libffi/pull/263

"BG" == Ben Gamari
writes:
BG> Note that under this scheme it will still be possible to link against the BG> system's libffi installation using ./configure's --enable-system-libffi BG> flag. Will distributions of GHC be using a system libffi which still has the bugs you mentioned? -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

John Wiegley
"BG" == Ben Gamari
writes: BG> Note that under this scheme it will still be possible to link against the BG> system's libffi installation using ./configure's --enable-system-libffi BG> flag.
Will distributions of GHC be using a system libffi which still has the bugs you mentioned?
My inclination would be to use the system libffi unless this option is precluded due to bugs. By this standard I believe the only GHC HQ binary distributions which would include an unreleased libffi would those for ARM and AArch64. Cheers, - Ben

On Tuesday, September 26, 2017 9:38:11 PM EDT Ben Gamari wrote:
Numerous attempts have been made to get the libffi maintainers to cut a new release but sadly no progress has been made in over six months of trying.
Has anyone followed the process described in the somewhat poorly named https://wiki.haskell.org/Taking_over_a_package to try to add one or more maintainers upstream? If the current maintainer(s) object to that, would it make sense to produce a proper fork on Hackage? David

Aren't we talking about the C project here? https://sourceware.org/libffi/
--
Mathieu Boespflug
Founder at http://tweag.io.
On 28 September 2017 at 06:27, David Feuer
On Tuesday, September 26, 2017 9:38:11 PM EDT Ben Gamari wrote:
Numerous attempts have been made to get the libffi maintainers to cut a new release but sadly no progress has been made in over six months of trying.
Has anyone followed the process described in the somewhat poorly named https://wiki.haskell.org/Taking_over_a_package to try to add one or more maintainers upstream? If the current maintainer(s) object to that, would it make sense to produce a proper fork on Hackage?
David _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Yes. that’s the one.
On Sep 28, 2017, at 3:56 PM, Boespflug, Mathieu
wrote: Aren't we talking about the C project here? https://sourceware.org/libffi/ -- Mathieu Boespflug Founder at http://tweag.io.
On 28 September 2017 at 06:27, David Feuer
wrote: On Tuesday, September 26, 2017 9:38:11 PM EDT Ben Gamari wrote:
Numerous attempts have been made to get the libffi maintainers to cut a new release but sadly no progress has been made in over six months of trying.
Has anyone followed the process described in the somewhat poorly named https://wiki.haskell.org/Taking_over_a_package to try to add one or more maintainers upstream? If the current maintainer(s) object to that, would it make sense to produce a proper fork on Hackage?
David _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (5)
-
Ben Gamari
-
Boespflug, Mathieu
-
David Feuer
-
John Wiegley
-
Moritz Angermann