From: Anthony Green <green@moxielogic.com>
To: libffi-discuss <libffi-discuss@sourceware.org>, jeremyhu@apple.com
Cc: jlaw@tachyum.com
Subject: Re: Aiming for a libffi release in the next two weeks
Date: Sat, 26 Jun 2021 12:19:54 -0400 [thread overview]
Message-ID: <CACxje596cbCMFsaZfmApzqN9ELBoYn3hc8vKUnkk823v7ZF3xQ@mail.gmail.com> (raw)
In-Reply-To: <CACxje5_d6WuN_x-95SaJyH34rAw2Nd_2wYKny7PcX-HxAfQE+Q@mail.gmail.com>
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.
>
>
next prev parent reply other threads:[~2021-06-26 16:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 19:50 Anthony Green
2021-06-15 19:52 ` Jeff Law
2021-06-26 16:19 ` Anthony Green [this message]
2021-06-26 19:59 ` Jeremy Huddleston Sequoia
2021-06-26 20:13 ` Anthony Green
2021-06-28 14:09 ` Anthony Green
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACxje596cbCMFsaZfmApzqN9ELBoYn3hc8vKUnkk823v7ZF3xQ@mail.gmail.com \
--to=green@moxielogic.com \
--cc=jeremyhu@apple.com \
--cc=jlaw@tachyum.com \
--cc=libffi-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).