This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Introduce --enable-math-noprivate
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Cc: nd at arm dot com
- Date: Fri, 8 Jun 2018 10:03:40 +0100
- Subject: Re: [PATCH] Introduce --enable-math-noprivate
- Nodisclaimer: True
- References: <20180511154314.83126424B00CE@oldenburg.str.redhat.com> <edc5d16c-c095-0766-fadd-3d5ba7b6c26d@redhat.com> <81a58bc9-7069-3b9f-6b70-bd68d626990b@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 07/06/18 14:38, Florian Weimer wrote:
On 05/16/2018 06:54 AM, Florian Weimer wrote:
On 05/11/2018 05:43 PM, Florian Weimer wrote:
Avoid errno@GLIBC_PRIVATE if enabled. Additional work is needed
to eliminate further GLIBC_PRIVATE symbol references.
2018-05-11 Florian Weimer<fweimer@redhat.com>
Introduce --enable-math-noprivate.
Avoid errno@GLIBC_PRIVATE if enabled.
* config.h.in (CONFIG_MATH_NOPRIVATE): Define.
* config.make.in (config-math-noprivate): New variable.
* configure.ac: Recognize --enable-math-noprivate option.
* manual/install.texi (Configuring and compiling): Document
--enable-math-noprivate.
* configure: Regenerate.
* INSTALL: Likewise.
* include/errno.h: Do not redefine errno for libm, libmvec if
CONFIG_MATH_NOPRIVATE.
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)
if one updates libm.so will that also update math.h?
or we just want a libm with backward compatible abi?
either way i think it should be possible to do and
since glibc is currently very hard to update on a
system it can be useful.