I release 3.4.2 yesterday! Thanks to everyone who contributed! To be honest, with the CI infrastructure falling apart in the last few weeks, I'm guessing we may need to make fast-following 3.4.x releases, but we'll see. Job number one is really moving as much CI to github actions as quickly as possible. I know that various Linux distro build systems are very active right now, and I'm hopeful that we'll see this in wide usage very soon. Thanks again, AG ---------- Forwarded message --------- From: Anthony Green <green@moxielogic.com> Date: Tue, Jun 29, 2021 at 5:10 PM Subject: Announcing libffi 3.4.2 To: <libffi-announce@sourceware.org> I'm very pleased to announce the release of libffi version 3.4.2, which you are free to download here: https://github.com/libffi/libffi/releases/download/v3.4.2/libffi-3.4.2.tar.gz Here are some of the highlights of this release: 3.4.2 Jun-28-21 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. 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. Of particular note is Madhavan Venkataraman's static trampoline work, as it can eliminate the need for writeable/executable memory under certain conditions. As usual, many thanks to all of the contributors! Check out the following links for more details: https://sourceware.org/libffi https://github.com/libffi/libffi Have fun! Anthony Green green@moxielogic.com https://twitter.com/antgreen
Hi Anthony,
In February 2020, you asked in the thread "Another libffi ABI change and another
release" about a new release. Pings in July 2020 and November were unanswered.
3.3 had a similar release process, with a pending release for more than two
years. Now rushing a new release just for the sake of a single distro seems odd,
maybe there is some room for improvement in the release process?
When looking at 3.4.2 (after announcing 3.4),
- libtool-version says the abi version is 9, but that seems
to be ignored. Where is the definition of the ABI version
coming from?
- README.md talks about 3.4.1, not 3.4.2.
I packaged 3.4.2 for Debian (the only way I can test it on the Debian
infrastructure), it needs manual approval for the renamed library package, so I
can't give feedback on test results yet, and have to wait until its built.
Tests for the Ubuntu architectures pass.
Do you plan to update the libffi copy within GCC to this release? If not,
could you give instructions, how the two copies are managed in your VCS, and
what is the best way to merge those?
I just saw your ping on #libffi on Freenode on Monday, however you are seldom be
present on this channel. Is this channel still somewhat official, Is it moved
to Libera.Net as everything else? If yes, maybe mention the channel on the
libffi home page as well.
Thanks, Matthias
On 6/29/21 11:17 PM, Anthony Green wrote:
> I release 3.4.2 yesterday! Thanks to everyone who contributed!
>
> To be honest, with the CI infrastructure falling apart in the last few
> weeks, I'm guessing we may need to make fast-following 3.4.x releases,
> but we'll see. Job number one is really moving as much CI to github
> actions as quickly as possible.
>
> I know that various Linux distro build systems are very active right
> now, and I'm hopeful that we'll see this in wide usage very soon.
>
> Thanks again,
>
> AG
>
> ---------- Forwarded message ---------
> From: Anthony Green <green@moxielogic.com>
> Date: Tue, Jun 29, 2021 at 5:10 PM
> Subject: Announcing libffi 3.4.2
> To: <libffi-announce@sourceware.org>
>
>
> I'm very pleased to announce the release of libffi version 3.4.2, which
> you are free to download here:
>
> https://github.com/libffi/libffi/releases/download/v3.4.2/libffi-3.4.2.tar.gz
>
> Here are some of the highlights of this release:
>
> 3.4.2 Jun-28-21
> 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.
> 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.
>
> Of particular note is Madhavan Venkataraman's static trampoline work,
> as it can eliminate
> the need for writeable/executable memory under certain conditions.
>
> As usual, many thanks to all of the contributors!
>
> Check out the following links for more details:
> https://sourceware.org/libffi
> https://github.com/libffi/libffi
>
> Have fun!
>
> Anthony Green
> green@moxielogic.com
> https://twitter.com/antgreen
>
On Thu, Jul 1, 2021 at 6:01 AM Matthias Klose <doko@ubuntu.com> wrote: > maybe there is some room for improvement in the release process? Yes, there definitely is! > When looking at 3.4.2 (after announcing 3.4), > > - libtool-version says the abi version is 9, but that seems > to be ignored. Where is the definition of the ABI version > coming from? libtool-version is not being ignored. libtool computes the so number to be CURRENT - AGE, and 9 - 1 = 8. I don't pretend to understand the details of libtool and abi versioning. I'm just trusting that libtool is doing the right thing. > - README.md talks about 3.4.1, not 3.4.2. Whoops. That was a miss. I suspect that there will be a 3.4.3 soon enough where we can correct it. > I packaged 3.4.2 for Debian (the only way I can test it on the Debian > infrastructure), it needs manual approval for the renamed library package, so I > can't give feedback on test results yet, and have to wait until its built. > Tests for the Ubuntu architectures pass. That's great. Note that some packages that depend on libffi are broken with the new static trampoline code. See https://github.com/libffi/libffi/pull/647 for details. You might want to compile with --disable-exec-static-tramp until they get sorted out. This will not change the ABI. > Do you plan to update the libffi copy within GCC to this release? If not, > could you give instructions, how the two copies are managed in your VCS, and > what is the best way to merge those? I have not been involved in gcc's libffi copy for many many years (since well before gcj was removed). In the past, I've promoted the idea that it be removed from GCC, and that people who need it just build it separately, like other external dependencies. The main challenge will be that the configury has diverged somewhat over the years. > I just saw your ping on #libffi on Freenode on Monday, however you are seldom be > present on this channel. Is this channel still somewhat official, Is it moved > to Libera.Net as everything else? If yes, maybe mention the channel on the > libffi home page as well. Yes, let's make a new channel elsewhere. libera.net is as good a place as any. Thank you for the feedback, Matthias. I'm sorry if this release has caused you trouble, especially on account of all of the great help you've provided over the years. BTW, this year marks the 25th year since the first release.... wow. AG