On Tue, 06 Nov 2012 at 09:42:48 +0100, Sjoerd Simons wrote: > This obviously breaks ABI on these platforms, not only of glib but also of > libraries which have a GStaticMutex embedded in their public structs in some > way.
I sent this upstream, GNOME #688406. The new ABI has already been in two upstream stable branches, so reverting it would be just as painful from their point of view (and, I suspect, ours - testing is in an inconsistent state where some things have been recompiled, but not everything). In general, 32-bit RISC architectures are affected. i386 is unaffected because its ABI only aligns doubles on 32-bit boundaries, and 64-bit architectures are unaffected because the pointer at the beginning of GStaticMutex aligns the next struct member at a 64-bit boundary without needing padding. Confirmed affected: armel, armhf, mipsel, powerpc, s390, sparc (see https://bugzilla.gnome.org/show_bug.cgi?id=688406 for a standalone test) Suspected to be affected, but I couldn't log into a porterbox: armeb, mips, powerpcspe (of which mips is the only release architecture) Confirmed unaffected: amd64, i386, ia64, sh4, s390x Suspected to be unaffected, but I couldn't log into a porterbox: alpha, ppc64, sparc64 (all 64-bit, none are release architectures?) Untested: kfreebsd-i386, kfreebsd-amd64, hurd-i386 (assumed to have the same struct member alignment requirements as Linux, in which case all are unaffected) No idea: hppa, m68k (not release architectures anyway) One mitigating factor is that since GLib 2.32, only the first sizeof(void *) bytes of a GStaticMutex are actually used - so in global static mutexes, the most common use, it doesn't actually matter. The problem cases are structs that contain a GStaticMutex, and either are a GObject, or have members after the GStaticMutex. In GLib, GStaticRWLock and GStaticRecMutex are also affected (they contain a GStaticMutex). I haven't done the trawl through codesearch.debian.net to find out whether they're in anything else's public headers. > Whatever we do, we do need to ensure that all affected software gets compiled > against whatever final solution we pick. My vote would be to use codesearch.debian.net to find all affected software, and binNMU it on all release architectures, plus all affected unofficial architectures that have the infrastucture for binNMUs. The slower official architectures need the binNMU anyway, because they're precisely the 32-bit non-x86 architectures that are affected. If we binNMU on the unaffected official architectures - any-i386, any-amd64 and ia64 - as well, it shouldn't take any longer (they're "fast" architectures), and keeping the binNMU version in sync between architectures will make more multiarch packages co-installable. S -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
