This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Legacy _IO_* symbols and Flaot128 transition
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "Gabriel F. T. Gomes" <gabrielftg at linux dot ibm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 2 Jul 2018 09:22:03 +0200
- Subject: Re: Legacy _IO_* symbols and Flaot128 transition
- References: <a3d90e92-832e-4ca3-987d-acaff7ff5093@redhat.com> <20180629122600.1062b3bc@tereshkova> <1d310ac2-64f8-21d7-3bc5-2ddfa871f348@redhat.com> <alpine.DEB.2.20.1806291706070.24607@digraph.polyomino.org.uk>
On 06/29/2018 07:15 PM, Joseph Myers wrote:
On Fri, 29 Jun 2018, Florian Weimer wrote:
Should they be turned into compat symbols *because* they won't be
installed headers (and we don't want new user code linking against them)?
Or is there something else to it?
No, it's just a cleanup, and to clarify what's necessary for future work.
Anything not accessible from installed headers is a good candidate for
making into a compat symbol.
Agreed.
I also want to add some minimal test for libnldbl_nonshared.a, and reducing
its size helps with that. (I'm aware that on ppc64, the current toolchain
doesn't support long double as double anymore, but I can just lie to the
compiler and use double instead, I guess.)
It certainly appears to be supported to me (using GCC mainline, compiling
with -mlong-double-64 produces sizeof (long double) == 8 for both
powerpc64 and powerpc64le).
Oh, this option isn't documented for POWER, so I didn't try it.
However, libnldbl_nonshared.a is for long double = double *with compilers
not supporting asm redirection*. Which is a case the (incorrect) patch in
<https://sourceware.org/ml/libc-alpha/2014-08/msg00497.html> provides
evidence hasn't worked for a long time. So I still think there's a case
for eliminating libnldbl_nonshared.a and explicitly requiring asm
redirection support for these non-default long double variants, which it's
in practice required already (if not more generally requiring it for any
compiler using the glibc headers), as discussed in
<https://sourceware.org/ml/libc-alpha/2018-03/msg00281.html>.
Okay, I review the situation to determine which way is the best way
forward for the 2.28 release.
(The actual __nldbl_* exports from the glibc shared libraries - the
functions that get used with -mlong-double-64 given asm redirection
support - *should* be tested, via building some tests with
-mlong-double-64. The binary128 work should, as per
<https://sourceware.org/ml/libc-alpha/2018-06/msg00680.html>, add tests
that are generic to different long double formats, so that it will then be
easy to build them for -mlong-double-64 for ldbl-opt configurations.)
I suppose we should also add tests for the functions which are not
redirected to __nldbl_* variants, but to the non-l variants (because
only for things like printf, separate wrappers are needed if there is
redirection support).
Thanks,
Florian