Source: glib2.0
Version: 2.84.4-1
Severity: serious
Justification: https://release.debian.org/testing/rc_policy.txt ยง6a
User: [email protected]
Usertags: i386
User: [email protected]
Usertags: regression
X-Debbugs-Cc: [email protected]
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
