On 2020-07-24 15:23, Simon McVittie wrote:
> On Fri, 24 Jul 2020 at 14:36:54 +0200, Bastian Blank wrote:
> > On Fri, Jul 24, 2020 at 10:11:04AM +0100, Simon McVittie wrote:
> > > 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
> >
> > Because the binary was not linked with -lm, the linker never saw the
> > real symbol __atan2_finite@GLIBC2_16, so the linke only emitted a reference
> > to __atan2_finite.
>
> Right. However, note that there's no mention of __atan2_finite() in the
> source code - it's only used because older glibc would replace atan2()
> with a reference to __atan2_finite() when building with -ffast-math.
I do not see what does it change. atan2 also need to be linked with
-libm. If it is not, issues like the one you encountered might happen.
The change from atan2 to __atan2_finite when -ffast-math is in used is
purely done in the preprocessor.
> > At least dpkg-shlibdeps or so should warn about that.
>
> For at least openarena, it doesn't seem to. I'm not sure why not.
>
> For the next update to openarena I'm going to build it with -Wl,-z,defs
> so that missing dependencies are always fatal. However, that isn't
> always applicable: some plugin architectures (like Python extensions)
> rely on being able to pick up symbols exported by the executable, which
> are not necessarily programmatically distinguishable from symbols that
> are defined by libraries used by the executable.
This is indeed an issue, under-linking is sometimes difficult to find.
Given we now the list of affected symbols, I'll try to check if other
binaries are affected so that they can be fixed even if no users report
an issue.
> > > I've been trying to put together a standalone reproducer that only uses
> > > libdl and libm, but so far I have not been successful.
> >
> > Something like that?
> >
> > | % cat test.c
> > | void __atan2_finite(void);
> > | void test(void) {
> > | __atan2_finite();
> > | }
>
> I was aiming for something a bit closer to openarena's situation,
> where there is no explicit reference to __atan2_finite() in the source
> code: it calls atan2(), and cc -ffast-math rewrites that into a call
> to __atan2_finite(). I've now managed to make this work: see attached.
>
> Compile them and run ./prog in a buster environment (or an outdated
> bullseye/sid environment with glibc < 2.31), then run ./prog in an
> up-to-date bullseye/sid environment without recompiling.
>
> libmymodule.so will get a dynamic reference to __atan2_finite.
>
> The historical result is that prog outputs 0.463648, twice.
>
> The result in up-to-date bullseye/sid is that prog outputs 0.463648,
> once, and then fails with "undefined symbol: __atan2_finite".
>
> Using __FINITE_MATH_ONLY__ (which is defined by -ffast-math) is necessary
> to be able to reproduce the bug this way.
>
> If you consider this sort of thing to be too niche to be supportable,
> please feel free to close the bug.
I do consider it a bug on the openarena side, as it's basically using a
non-versioned symbol due to under-linking. However from the user point
of view, we should prevent that to happen, so I'll add the corresponding
Breaks: entry on the glibc side to ensure a flawless upgrade for the
users.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
