Package: libc6 Version: 2.31-1 Severity: normal I've encountered an odd bug in openarena (#966150) which I'm concerned might be a glibc regression affecting other packages.
Some background: openarena is a game running on the ioquake3 engine (main executable: /usr/lib/ioquake3/ioquake3). During startup, the engine dlopens some modules, which implement the actual openarena game and UI. One of those modules is uix86_64.so. uix86_64.so uses mathematical functions from libm, but is not itself linked to libm. At runtime (at least on older systems) it works as intended, because the ioquake3 executable *is* linked to libm. I'm aware that this is not the most robust setup, and uix86_64.so would ideally be linked with -lm to make it self-contained; but it's documented as being expected to work, and has always worked in the past: Symbol references in the shared object are resolved using (in order): symbols in the link map of objects loaded for the main program and its dependencies; [... and some more places ...] — dlopen(3) The bug (#966150) is that a version of uix86_64.so compiled with a slightly older (2020-02-18) toolchain fails to load on an up-to-date sid system, with: undefined symbol: __atan2_finite If I recompile openarena in a sid chroot, *with no source code changes* (in particular uix86_64.so is still not linked to -lm!), then it starts to work again. The recompiled uix86_64.so has an undefined reference to atan2, but no reference to __atan2_finite any more. I'm going to address this in bullseye by making openarena more robust (explicitly linking to -lm). After I've done that, the updated version of openarena will not be suitable as a reproducer for this bug report, but the buster version of openarena will still be suitable. If you believe this is not a significant regression in glibc and should only be fixed by changes in openarena, I have no problem with doing that and just closing this bug report. However, I wanted to raise this in case it affects other previously-built binaries. This can be reproduced somewhat conveniently as follows: * Have a buster virtual machine * Install openarena and enough of a desktop to get a terminal in an X11 environment * Run openarena * It succeeds * To exit quickly: Shift+Escape, type "/quit", Enter * Add a bullseye apt source and "apt update", but do not upgrade everything * Upgrade libc6 from 2.28-10 to 2.31-1, while upgrading as few other packages as possible * I used aptitude, which made me also upgrade gcc-9 and related packages, removing gcc-8 * Run openarena * It fails as described in #966150 * Downgrade libc6 and closely-related packages from 2.31-1 to 2.28-10 * In my case this meant downgrading libc-dev-bin, libc6-dev, libc6 and libc-bin, and removing libcrypt-dev and libcrypt1 * Run openarena * It succeeds again, confirming that this was a glibc behaviour change I've been trying to put together a standalone reproducer that only uses libdl and libm, but so far I have not been successful. I believe this is related to a change in the representation of the __atan2_finite symbol, which is used (at least by versions of openarena compiled against older glibc) because openarena is compiled with -ffast-math. In 2.28-10, that symbol was not hidden: $ objdump -Tx /lib/x86_64-linux-gnu/libm.so.6 ... 0000000000028280 g iD .text 0000000000000046 GLIBC_2.15 __atan2_finite In 2.31-1, it is hidden, and there is no non-hidden definition (default symbol-version): $ objdump -Tx /lib/x86_64-linux-gnu/libm.so.6 ... 000000000002a1e0 g iD .text 0000000000000049 (GLIBC_2.15) __atan2_finite Because uix86_64.so is not directly linked to -lm, it has an undefined reference to __atan2_finite with no particular version: $ objdump -Tx /usr/lib/openarena/baseoa/pak6-patch088/uix86_64.so ... 0000000000000000 D *UND* 0000000000000000 __atan2_finite As far as I can work out, this unversioned undefined reference can be satisfied by __atan2_finite@@GLIBC_2.15 in the global namespace from the old libm, but not by the hidden version __atan2_finite@GLIBC_2.15 in the new libm. Thanks, smcv