From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 080DF13933E for ; Wed, 7 Jul 2021 23:21:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02B3CE0D5C; Wed, 7 Jul 2021 23:21:04 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DF0FCE0D2E for ; Wed, 7 Jul 2021 23:21:02 +0000 (UTC) Date: Thu, 8 Jul 2021 00:20:58 +0100 From: Sergei Trofimovich To: gentoo-dev@lists.gentoo.org Cc: Toralf =?UTF-8?B?RsO2cnN0ZXI=?= Subject: [gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon) Message-ID: <20210708002058.71ea41ae@zn3> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: cb34f03c-a897-4610-8882-8a979ac480d5 X-Archives-Hash: 576259af17d008d4ec935f69a9049af7 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