Bug#1122038: libc6-dev: symbols not covering GLIBC_ABI_GNU_TLS on i386
On 2025-12-06 19:58, Adrian Bunk wrote:
> On Sat, Dec 06, 2025 at 05:51:51PM +0100, Aurelien Jarno wrote:
> > Hi,
> >
> > On 2025-12-06 14:59, Samuel Thibault wrote:
> > > Samuel Thibault, le sam. 06 déc. 2025 14:53:44 +0100, a ecrit:
> > > > Adrian Bunk, le sam. 06 déc. 2025 07:22:50 +0200, a ecrit:
> > > > > https://ci.debian.net/packages/s/starpu/testing/i386/66851610/
> > > > >
> > > > > ...
> > > > > 45s starpu_machine_display: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_ABI_GNU_TLS' not found (required by starpu_machine_display)
> > > > > ...
> > > > >
> > > > >
> > > > > This can be reproduced with starpu-tools/unstable and libc6/forky:
> > > > >
> > > > > $ starpu_machine_display
> > > > > starpu_machine_display: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_ABI_GNU_TLS' not found (required by starpu_machine_display)
> > > >
> > > > And more generally, a mere program int main(void) {} compiled with
> > > > unstable gets this error in forky. Libraries are not affected.
> > >
> > > (for the background, this symbol is apparently on purpose on i386:
> > > https://sourceware.org/git/?p=glibc.git;a=commit;h=ed1b7a5a489ab555a27fad9c101ebe2e1c1ba881
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=32996 )
> >
> > Yes. And the symbol is actually correctly covered in the symbols file.
> > But it is exported as part of the .gnu.version_r section, which is not
> > checked by dpkg-gensymbols.
> >
> > At this stage, I do not have more idea than forcing the minimum version
> > to 2.42 on i386. That will be for all binaries, not the ones actually
> > needing that (e.g. libraries).
>
> Urgent is to get a fixed/workarounded glibc before the chroot rebuilds
> tomorrow evening, package builds updating libc6 are rare and so far only
> a dozen packages are affected but staring Monday the binNMU list would
> become huge.
>
> Updating trixie to the latest 2.41 git would bring the same issue there.
>
> Add GLIBC_ABI_GNU_TLS version to indicate that glibc has the working
> GNU TLS run-time. Linker can add the GLIBC_ABI_GNU_TLS version to
> binaries which depend on the working TLS run-time so that such programs
> and shared libraries will fail to load and run at run-time against
> libc.so without the GLIBC_ABI_GNU_TLS version, instead of fail silently
> at random.
From the glibc point of view, backporting this fix, means a fixed glibc
2.41 (or older) is able to build many binaries from glibc 2.42. However
the dependency system we have in Debian has some difficulties to express
that. I guess one way would be to make GLIBC_ABI_GNU_TLS corresponds to
a Provides, but anyway dpkg-gensymbols is not able to see the
dependency...
> Doesn't this say that it is a bug when every single program picks up a
> dependency on GLIBC_ABI_GNU_TLS?
Or rather, this is a limitation of the linker system which can't easily
add a symbol depending if TLS is used or not in the binary.
> Unless I misunderstand something all this is about a glibc-internal
> bugfix for a (rare) bug, not any ABI change/addition.
Well, the original bug being fixed is the corruption of XMM registers
with the TLS helper. Yes, this has been exposed due to changes in the
malloc code, but could have been exposed by user code (e.g. malloc
interposers). So even if rare, this can have serious consequences, and
need to be fixed.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: