Math changes in glibc 2.31

Math changes in glibc 2.31

[Damien Zammit]

Hi,

Regarding the release of 2.31 of glibc (is this the right channel of enquiry?)

https://lists.gnu.org/archive/html/info-gnu/2020-02/msg00001.html

I heard that binaries previously compiled with `-ffast-math -fno-finite-math-only` won't run on new systems.
Why did this have to change?  This is going to create havoc especially with audio packages that heavily optimise.

Damien Zammit
ZamAudio

Re: Math changes in glibc 2.31

[Florian Weimer via Libc-alpha]

* Damien Zammit:

> Regarding the release of 2.31 of glibc (is this the right channel of enquiry?)
>
> https://lists.gnu.org/archive/html/info-gnu/2020-02/msg00001.html
>
> I heard that binaries previously compiled with `-ffast-math
> -fno-finite-math-only` won't run on new systems.  Why did this have to
> change?  This is going to create havoc especially with audio packages
> that heavily optimise.

What failures did you see?  It's hard to comment on rumors.

Thanks,
Florian

Re: Math changes in glibc 2.31

[Adhemerval Zanella via Libc-alpha]

On 09/05/2020 19:16, Damien Zammit wrote:
> Hi,
> 
> Regarding the release of 2.31 of glibc (is this the right channel of enquiry?)
> 
> https://lists.gnu.org/archive/html/info-gnu/2020-02/msg00001.html
> 
> I heard that binaries previously compiled with `-ffast-math -fno-finite-math-only` won't run on new systems.
> Why did this have to change?  This is going to create havoc especially with audio packages that heavily optimise.
> 
> Damien Zammit
> ZamAudio
> 

The *_finite symbols are exported now as compatibility symbols, meaning 
that old binaries will continue to run.  The change was done because the
-ffinite-math-only requires extra work and organization by the library 
and recent math optimizations (expf, exp2f, logf, etc.) have been improved
to handle the special cases and the *_finite names are just aliases (there
are some discussion in the original thread [1]).

[1] https://sourceware.org/legacy-ml/libc-alpha/2019-03/msg00395.html

Re: Math changes in glibc 2.31

[Damien Zammit]

On 11/5/20 9:05 pm, Florian Weimer wrote:
> * Damien Zammit:
>> I heard that binaries previously compiled with `-ffast-math
>> -fno-finite-math-only` won't run on new systems.  Why did this have to
>> change?  This is going to create havoc especially with audio packages
>> that heavily optimise.
> 
> What failures did you see?  It's hard to comment on rumors.

Actually, it is the flag -ffinite-math-only and any other flags that imply it
that causes symbols such as "expf_finite" to be created in binaries,
but apparently the new glibc 2.31 does not define these symbols anymore.

A workaround we found was that when using -ffast-math, we should also use -fno-finite-math-only,
but that has other implications regarding NaN/Inf values and other vectorised instructions
on arm for example.

Are you aware of this and do you have a recommended solution?

Cheers,
Damien Zammit

Re: Math changes in glibc 2.31

[Andrew Pinski via Libc-alpha]

On Mon, May 11, 2020 at 4:15 PM Damien Zammit <damien@zamaudio.com> wrote:
>
> On 11/5/20 9:05 pm, Florian Weimer wrote:
> > * Damien Zammit:
> >> I heard that binaries previously compiled with `-ffast-math
> >> -fno-finite-math-only` won't run on new systems.  Why did this have to
> >> change?  This is going to create havoc especially with audio packages
> >> that heavily optimise.
> >
> > What failures did you see?  It's hard to comment on rumors.
>
> Actually, it is the flag -ffinite-math-only and any other flags that imply it
> that causes symbols such as "expf_finite" to be created in binaries,
> but apparently the new glibc 2.31 does not define these symbols anymore.
>
> A workaround we found was that when using -ffast-math, we should also use -fno-finite-math-only,
> but that has other implications regarding NaN/Inf values and other vectorised instructions
> on arm for example.
>
> Are you aware of this and do you have a recommended solution?

So you have some .o or static libraries that are compiled with the old
headers from previous versions of glibc and then trying to link with
the latest version of glibc?
That is itself is not a supported use case IIRC for backwards
compability of glibc.

Thanks,
Andrew Pinski

Re: Math changes in glibc 2.31

[Damien Zammit]

Hi,

On 12/5/20 9:26 am, Andrew Pinski wrote:
> So you have some .o or static libraries that are compiled with the old
> headers from previous versions of glibc and then trying to link with
> the latest version of glibc?
> That is itself is not a supported use case IIRC for backwards
> compability of glibc.

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.

Distros of GNU/Linux don't have this problem because they recompile everything from scratch,
and for example, include the headers for the glibc that are installed on the distro.
However, I'm now unable to distribute a single binary that works across different distros,
because it now depends on which glibc they have installed.  I was able to do this previously.

Why is this kind of backward compatibility not a fundamental feature of something
as vital as the GNU C library?

Is there a way I can still distribute a single binary for example, if I ensure I compile 
my binary using latest glibc headers?

Cheers,
Damien

Re: Math changes in glibc 2.31

[Samuel Thibault]

Damien Zammit, le mar. 12 mai 2020 10:07:20 +1000, a ecrit:
> On 12/5/20 9:26 am, Andrew Pinski wrote:
> > So you have some .o or static libraries that are compiled with the old
> > headers from previous versions of glibc and then trying to link with
> > the latest version of glibc?
> > That is itself is not a supported use case IIRC for backwards
> > compability of glibc.
> 
> 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.

Samuel

Re: Math changes in glibc 2.31

[Samuel Thibault]

Damien Zammit, le mar. 12 mai 2020 10:07:20 +1000, a ecrit:
> compile a binary on a slightly [...] newer system and give it/sell it
> to someone else to run.

That case is generally never going to work with any kind of library on
the market. Libraries will make sure you can run an old binary on a
newer system, but not the converse: they will introduce newer functions,
which your binary might end up calling, and thus be incompatible with
systems using the earlier version.

So yes, one has to build on the oldest system one wants to provide
compatibility for, that's true for all libraries.

Samuel

Re: Math changes in glibc 2.31

[Damien Zammit]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

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

According to what you are telling me, this binary should resolve the *_finite symbols
via the compatibility symbols in glibc 2.31, but that's not what the user experienced
in the report above.

Damien

[-- Attachment #2: a-eq.so.gz --]
[-- Type: application/gzip, Size: 8179 bytes --]

Re: Math changes in glibc 2.31

[Aurelien Jarno]

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

Re: Math changes in glibc 2.31

[Samuel Thibault]

Damien Zammit, le mar. 12 mai 2020 11:10:44 +1000, a ecrit:
> $ 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
> 
> According to what you are telling me, this binary should resolve the *_finite symbols
> via the compatibility symbols in glibc 2.31,

Yes.
An objdump of his libm.so would confirm whether it exposes __expf_finite
or not. If not, his distribution seems to be doing a poor job as in not
even running the testsuite that would have checked for the presence of
the symbol.

Samuel

Re: Math changes in glibc 2.31

[Florian Weimer via Libc-alpha]

* Damien Zammit:

> 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

It would have been nice to mention that at the start of this thread, so
that we could reply there before the topic was closed. 8-/

Would you be able to contact the forum moderators to reopen this thread?

> I have extracted one of the problematic binaries from Ardour 5.12's
> official package and attached it below.

Thanks, this is useful.

$ readelf -dW a-eq.so 

Dynamic section at offset 0x3600 contains 25 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0xe28
[…]

The binary is not linked against libm.so.6, but uses symbols from the
math library.  I see the same issue in the Fedora build.  This is a bug
in the Ardour build process.  It really needs to link against the
appropriate libraries.

Thanks,
Florian

Re: Math changes in glibc 2.31

[Damien Zammit]

Hi Florian,

On 12/5/20 7:49 pm, Florian Weimer wrote:
> It would have been nice to mention that at the start of this thread, so
> that we could reply there before the topic was closed. 8-/

My apologies.

I should have opened my query to this list with a link to the user's report.

> The binary is not linked against libm.so.6, but uses symbols from the
> math library.  I see the same issue in the Fedora build.  This is a bug
> in the Ardour build process.  It really needs to link against the
> appropriate libraries.

This has now been fixed in Ardour, (thanks Robin!)

I will make an effort to tell others to ensure they link their binaries to -lm,
where appropriate, and that -fno-finite-math-only can be dropped if desired.

Thanks,
Damien

Re: Math changes in glibc 2.31

[Florian Weimer via Libc-alpha]

* Damien Zammit:

>> The binary is not linked against libm.so.6, but uses symbols from the
>> math library.  I see the same issue in the Fedora build.  This is a bug
>> in the Ardour build process.  It really needs to link against the
>> appropriate libraries.
>
> This has now been fixed in Ardour, (thanks Robin!)
>
> I will make an effort to tell others to ensure they link their
> binaries to -lm, where appropriate, and that -fno-finite-math-only can
> be dropped if desired.

Thanks, good to know.

Florian