Your message dated Fri, 6 Feb 2026 15:16:45 +0000
with message-id <[email protected]>
and subject line Re: Bug#1111373: glib2.0: autopkgtest regression on i386 since
2.84.4-1: statically linked program segfaults
has caused the Debian Bug report #1111373,
regarding glib2.0: autopkgtest regression on i386 since 2.84.4-1: statically
linked program segfaults
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1111373: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111373
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On Sun, 17 Aug 2025 at 14:43:58 +0100, Simon McVittie wrote:
On Sun, 17 Aug 2025 at 14:12:52 +0100, Simon McVittie wrote:
In glib2.0 since 2.84.4-1, the autopkgtest test-cases "libglib2.0-dev"
and "build-static" are failing on i386 only
I could not immediately reproduce this in a sid podman container
...
It is also not reproducible on ci.debian.net when retried today, so,
*shrug* maybe we will never know what happened.
This doesn't seem to have recurred.
smcv
--- End Message ---
