Including libffi as a submodule

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Including libffi as a submodule

Ben Gamari-2

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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Including libffi as a submodule

John Wiegley-2
>>>>> "BG" == Ben Gamari <[hidden email]> 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
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Including libffi as a submodule

Ben Gamari-2
John Wiegley <[hidden email]> writes:

>>>>>> "BG" == Ben Gamari <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Including libffi as a submodule

David Feuer-2
In reply to this post by Ben Gamari-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Including libffi as a submodule

Boespflug, Mathieu
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Including libffi as a submodule

Moritz Angermann-2
Yes. that’s the one.

> On Sep 28, 2017, at 3:56 PM, Boespflug, Mathieu <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Including libffi as a submodule

David Feuer-2
In reply to this post by Ben Gamari-2
Sorry; wasn't thinking straight!



David Feuer
Well-Typed, LLP

-------- Original message --------
From: "Boespflug, Mathieu" <[hidden email]>
Date: 9/28/17 3:56 AM (GMT-05:00)
To: David Feuer <[hidden email]>
Cc: ghc-devs <[hidden email]>
Subject: Re: Including libffi as a submodule

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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs