Bug#674156: alignment issue

[Simon McVittie]

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