[PATCH] Introduce --enable-math-noprivate
Florian Weimer
fweimer@redhat.com
Fri Jun 8 12:11:00 GMT 2018
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
More information about the Libc-alpha
mailing list