Figure out what to do about libffi

For some platform GHC depends upon libffi for foreign call support in the bytecode interpreter. Unfortunately libffi's upstream seems to be unresponsive and there has not been a release in nearly three years. This means that there is currently no release which has, e.g., support for AArch64 and iOS's compact debug information.

While we obviously want to avoid shipping our own patched libffi, at this point we are starting to run out of options. Consider options for resolving this.

Trac metadata

Trac field	Value
Version	8.0.1
Type	Task
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	angerman
Operating system
Architecture

changed milestone to %8.4.1

changed weight to 5

added Ttask Trac import labels

mentioned in issue #14057

I really wonder how other languages that e.g. depend on the go support that was added after the last release handle this? Do they just depend on some repository hash?

For the record, angerman requested a new release from upstream in March. See https://github.com/libffi/libffi/issues/296.

libffcall is an alternative that the Caml folks have considered, but they also decided against it due to lack of maintenance.

dyncall is another.

changed milestone to %8.6.1

This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

closed

changed milestone to %8.4.1

For the record, we have started using a snapshot of libffi in e515c7f3. Until an alternative to libffi presents itself this will have to do.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

Status update: libffi upstream released a release candidate around a year ago. Unfortunately it seems like progress has since stalled. Nevertheless, CPython has started using it. We probably ought to follow suite.

mentioned in issue #15397

added Pnormal label