Bug#1111373: glib2.0: autopkgtest regression on i386 since 2.84.4-1: statically linked program segfaults

[Simon McVittie]

Source: glib2.0
Version: 2.84.4-1
Severity: serious
Justification: https://release.debian.org/testing/rc_policy.txt §6a
User: debian-qa at lists.debian.org
Usertags: i386
User: debian-ci at lists.debian.org
Usertags: regression
X-Debbugs-Cc: qemu at packages.debian.org

In glib2.0 since 2.84.4-1, the autopkgtest test-cases "libglib2.0-dev" 
and "build-static" are failing on i386 only:

> 148s + pkg-config --static --cflags --libs glib-2.0
> 148s + gcc -static -o glib-static glib.c -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 -pthread -lglib-2.0 -latomic -lm -pthread -lsysprof-capture-4 -pthread -lpcre2-8
> 148s /usr/bin/ld: /usr/lib/gcc/i686-linux-gnu/14/../../../i386-linux-gnu/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry':
> 148s (.text+0xed): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> 148s /usr/bin/ld: (.text+0x2bc): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> 148s /usr/bin/ld: (.text+0x12c): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> 148s + echo build (glib, static): OK
> 148s + [ -x glib-static ]
> 148s + foo=bar ./glib-static
> 148s build (glib, static): OK
> 148s Segmentation fault

None of the upstream changes between 2.84.3 and 2.84.4 look like obvious 
candidates for causing this, so I suspect it might be something more 
like "GLib was recompiled with a new compiler and that made it regress". 
I'm investigating.

If we can't easily address this within GLib, we might need to stop 
treating static linking as something that we expect to work on i386. I 
believe the main use-case is qemu-user static binaries, and qemu's 
build log says:

    Message: Support for 32-bit CPU host architecture x86 is going
    Message: to be dropped in a future QEMU release.

so that package's days are numbered anyway. Interestingly, qemu built 
successfully on i386 even with the new GLib - but I don't know whether 
it has any build-time smoke-tests that prove that it actually works.

This is blocking the fixes for #1110640, #1110825, #1110696 from 
migrating to forky.

    smcv