Tl;DR
-----
libffi-3.4 entered ::gento without KEYWORDS today.
After some testing it will be promoted into ~arch.
libffi has two modes:
1. USE=-exec-static-trampoline: old (default, safe)
2. USE=exec-static-trampoline: new (cool, might expose latent bugs)
+toralf@ (CC):
Toralf, can we set a tinderbox run for [1.]
>=dev-libs/libffi-3.4[-exec-static-trampoline]
case?
[2.] would also be nice:
>=dev-libs/libffi-3.4[exec-static-trampoline]
My worry is that it will generate a lot of collateral
breakage (at least some percentage of dev-haskell/*).
Tracker: https://bugs.gentoo.org/801109
Known examples: https://wiki.gentoo.org/index.php?title=Project:Toolchain#libffi-3.4
More help
---------
If you happen to maintain a Gentoo package that uses libffi
you can try libffi-3.4 early to see how it behaves.
- Try [1.] on packages you maintain.
- If you are brave try [2.] as well but be ready to recover
your system! A few packages are already known to be affected:
https://wiki.gentoo.org/index.php?title=Project:Toolchain#libffi-3.4
Add new bugs you found as blockers to the libffi-3.4 tracker:
https://bugs.gentoo.org/801109
More words
----------
In this release most probably impactful change is a trampoline
code handling change.
Before 3.4 libffi generated all code at runtime in a single
executable chunk of executable memory.
Since 3.4 libffi uses does not use runtime code generation and
uses statically defined trampoline in a very clever way:
https://sourceware.org/pipermail/libffi-discuss/2021/002579.html
This should not be a problem for most applications, but two
are already known to fail:
- ghc: https://gitlab.haskell.org/ghc/ghc/-/issues/20051
- gobject-introspection: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/283
The symptoms are SIGSEGVs and erratic behaviour.
To workaround widespread breakage libffi-3.4 provides a fallback mode
that reuses libffi-3.3 style trampoline layout via USE=-exec-static-trampoline.
Also note that libffi-3.4 also changes SONAME from libffi.so.7
to libffi.so.8. It will rebuild a few packages as a result.
It's a good time to check for missing rebuild slot operator in
depends.
If you broke your system with USE=exec-static-trampoline try to
recover with USE=-exec-static-trampoline first. It should avoid
rebuilding revdeps back to .so.7.
Debugging help
--------------
If you suspect your package is affected then CC toolchain@
to the relevant bug and we'll try to sort it out together.
Have fun!
--
Sergei
-----
libffi-3.4 entered ::gento without KEYWORDS today.
After some testing it will be promoted into ~arch.
libffi has two modes:
1. USE=-exec-static-trampoline: old (default, safe)
2. USE=exec-static-trampoline: new (cool, might expose latent bugs)
+toralf@ (CC):
Toralf, can we set a tinderbox run for [1.]
>=dev-libs/libffi-3.4[-exec-static-trampoline]
case?
[2.] would also be nice:
>=dev-libs/libffi-3.4[exec-static-trampoline]
My worry is that it will generate a lot of collateral
breakage (at least some percentage of dev-haskell/*).
Tracker: https://bugs.gentoo.org/801109
Known examples: https://wiki.gentoo.org/index.php?title=Project:Toolchain#libffi-3.4
More help
---------
If you happen to maintain a Gentoo package that uses libffi
you can try libffi-3.4 early to see how it behaves.
- Try [1.] on packages you maintain.
- If you are brave try [2.] as well but be ready to recover
your system! A few packages are already known to be affected:
https://wiki.gentoo.org/index.php?title=Project:Toolchain#libffi-3.4
Add new bugs you found as blockers to the libffi-3.4 tracker:
https://bugs.gentoo.org/801109
More words
----------
In this release most probably impactful change is a trampoline
code handling change.
Before 3.4 libffi generated all code at runtime in a single
executable chunk of executable memory.
Since 3.4 libffi uses does not use runtime code generation and
uses statically defined trampoline in a very clever way:
https://sourceware.org/pipermail/libffi-discuss/2021/002579.html
This should not be a problem for most applications, but two
are already known to fail:
- ghc: https://gitlab.haskell.org/ghc/ghc/-/issues/20051
- gobject-introspection: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/283
The symptoms are SIGSEGVs and erratic behaviour.
To workaround widespread breakage libffi-3.4 provides a fallback mode
that reuses libffi-3.3 style trampoline layout via USE=-exec-static-trampoline.
Also note that libffi-3.4 also changes SONAME from libffi.so.7
to libffi.so.8. It will rebuild a few packages as a result.
It's a good time to check for missing rebuild slot operator in
depends.
If you broke your system with USE=exec-static-trampoline try to
recover with USE=-exec-static-trampoline first. It should avoid
rebuilding revdeps back to .so.7.
Debugging help
--------------
If you suspect your package is affected then CC toolchain@
to the relevant bug and we'll try to sort it out together.
Have fun!
--
Sergei
