Re: [gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon)
On Sat, 17 Jul 2021 20:14:52 +0100 Sergei Trofimovich wrote: > On Thu, 8 Jul 2021 00:20:58 +0100 > Sergei Trofimovich wrote: > > > 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) > > Default USE=-exec-static-trampoline did not expose any new > failures over past week. > > If next week will be as calm we can unleash libffi into > ~arch next weekend (~24 July 2021). libffi-3.4.2 pushed to ~arch as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e03b5b8d5f1a5023dff4c341bb40578690471acb -- Sergei
Re: [gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon)
On Thu, 8 Jul 2021 00:20:58 +0100 Sergei Trofimovich wrote: > 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) Default USE=-exec-static-trampoline did not expose any new failures over past week. If next week will be as calm we can unleash libffi into ~arch next weekend (~24 July 2021). -- Sergei
[gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon)
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
