Re: [PATCH] Introduce --enable-math-noprivate

[Florian Weimer <fweimer at redhat dot com>]

On 06/08/2018 11:03 AM, Szabolcs Nagy wrote:

> > > Ping.  These patches
> > >
> > > <https://sourceware.org/ml/libc-alpha/2018-05/msg00501.html>
> > > <https://sourceware.org/ml/libc-alpha/2018-05/msg00541.html>
> > >
> > > allow building libm.so.6 without GLIBC_PRIVATE references on aarch64, 
> > > and on x86-64 if --disable-multi-arch is also specified (I have a 
> > > patch to add multi-arch support for the latter, but I need to come up 
> > > with something that reduces the maintenance burden).
> >
> > Ping?
> >
> > What's the general feeling regarding this feature?
>
> independently updatable libm can be useful
> (or something that works from an LD_LIBRARY_PATH)
> when users of a very-stable-distro want to use the
> latest libm (assuming libm improves over time) or
> somebody wants to provide a libm with different
> precision guarantees.
>
> but i can see that ifunc may be ugly to implement.
> (or soft float, or fenv or strtod using nan)

The strtod/nan part should be covered by the second patch.  I don't know 
yet what the problems with soft float will be.  To be honest, I'm not 
particularly interested in soft-float. 8-/

IFUNC handling need per-architecture changes.  On some targets, it 
simply means removing IFUNC resolvers which always return the same 
function.  On other targets, it requires to duplicate the dispatching 
logic found in libc inside libm.

There could be a problem if the dispatching logic depends on the 
auxiliary vector passed by the kernel.  libm will not have access to 
that during relocation.

> if one updates libm.so will that also update math.h?

I don't think that will be easy to support.

> or we just want a libm with backward compatible abi?

For now, yes.

Thanks,
Florian