Aiming for a libffi release in the next two weeks

[Anthony Green]

I've just published libffi 3.4 release candidate 1.  You can download and
test from here:
https://github.com/libffi/libffi/releases/tag/v3.4-rc1

I'd appreciate any feedback and hope to make the final release on Monday at
the latest.

AG


On Tue, Jun 15, 2021 at 3:50 PM Anthony Green <green@moxielogic.com> wrote:

> DJ brought to my attention the fact that we'll be missing important
> release windows for Fedora and downstream distros if we don't get
> something out the door in the next two weeks.  And I'm very excited about
> the improvements targeted for this release -- Madhavan's static trampoline
> work in particular.
>
> There are a number of PR and Issues that have been sitting around for a
> while.  Please bump them if you think they are important.
>
> One area I'd like some clarity on is "apple silicon" support.  Not being a
> Mac user, I'm looking at Apple and Jeremy Huddleston Sequoia for guidance
> here.  There's a big PR WIP sitting on github.
>
> Also.. travis-ci testing for MacOS hasn't been working for a long time
> thanks to homebrew timeouts.  Something got really slow here.   Does
> anybody have insight into this?
>
> As always, thank you for your contributions and patience.  Big shout out
> to DJ for his recent efforts.
>
> AG
>
> In the queue for 3.4...
>
>         Add static trampoline support for Linux on x86_64 and ARM64.
>         Add support for Alibaba's CSKY architecture.
>         Add support for Kalray's KVX architecture.
>         Add support for Intel Control-flow Enforcement Technology (CET).
>         Add support for ARM Pointer Authentication (PA).
>         Fix 32-bit PPC regression.
>         Fix MIPS soft-float problem.
>         Fox x86-64 nested struct varargs passing problem.
>         Enable tmpdir override with the $LIBFFI_TMPDIR environment
> variable.
>         Enable compatibility with MSVC runtime stack checking.
>         Reject float and small integer argument in ffi_prep_cif_var().
>           Callers must promote these types themselves.
>
>