Including libffi as a submodule

[Ben Gamari]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170926/fe118243/attachment.sig>