Math changes in glibc 2.31

Aurelien Jarno aurelien@aurel32.net
Tue May 12 07:35:52 GMT 2020


On 2020-05-12 11:10, Damien Zammit wrote:
> Hi,
> 
> On 12/5/20 10:16 am, Samuel Thibault wrote:
> > Damien Zammit, le mar. 12 mai 2020 10:07:20 +1000, a ecrit:
> >> Well, yes, it is a pretty nice feature to be able to compile a binary on a slightly
> >> older or newer system and give it/sell it to someone else to run.
> > 
> > He is *not* talking about a linked binary, but about a non-linked .o
> > file or .a archive.
> > 
> > If you link a binary and end up with an __expf_finite symbol, that
> > symbol will lookup fine with a 2.31 libm.so, because that *has*
> > compatibility symbols.
> 
> Ok, so I found the case I wanted to share with you:
> 
> Here is a link to a report from a user who tried to use an audio plugin
> (an old binary) and trying to run it on glibc 2.31 with compat symbols:
> 
> https://discourse.ardour.org/t/a-eq-and-a-comp-fail-on-manjaro-xfce/103122
> 
> I have extracted one of the problematic binaries from Ardour 5.12's official package
> and attached it below.
> 
> $ objdump -T a-eq.so |grep finite
> 0000000000000000      D  *UND*	0000000000000000              __pow_finite
> 0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 __finite
> 0000000000000000      D  *UND*	0000000000000000              __expf_finite
> 0000000000000000      D  *UND*	0000000000000000              __powf_finite
> 0000000000000000      D  *UND*	0000000000000000              __exp_finite
> 0000000000000000      D  *UND*	0000000000000000              __log10_finite

This library is not properly linked as the __*_finite symbols are not
properly versioned.

We have found a few packages like that in Debian, in general it happened
when they are not linked with -lm. See for example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954305

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


More information about the Libc-alpha mailing list