This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] include/bits/*-ldbl.h headers
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 24 Aug 2017 14:42:07 +0000
- Subject: Re: [PATCH] include/bits/*-ldbl.h headers
- Authentication-results: sourceware.org; auth=none
- References: <c21aed9d-08ee-e774-c905-a7cf5f755b83@redhat.com>
On Thu, 24 Aug 2017, Florian Weimer wrote:
> We are carrying this historic patch. I think such patches are necessary
> to prevent installed header files leaking into the build, but its
> curious that this isn't happening already. Should we apply this upstream?
These bits/*-ldbl.h files should only be used by -mlong-double-64
compilations. I don't think there are any such compilations in the glibc
build. We *should* have tests of -mlong-double-64 (that various affected
interfaces work properly for it; there are quite a lot of such interfaces,
and as I previously noted the printf-like functions in argp.h, err.h and
error.h are accidentally missing such compat versions), at which point
such include/ wrappers (or indeed more such wrappers) might be needed
depending on what directories the tests are in. But, right now, I
wouldn't expect such wrappers to be used in any compilations in building
or testing glibc (and if they were, check-local-headers failures should
result, or build failures if building with a --with-headers option
pointing to a path with only kernel headers).
(If you did linknamespace tests for -mlong-double-64 I expect you'd need
wrappers for all such bits/ headers. The reported sparc32 failures at
<https://sourceware.org/glibc/wiki/Release/2.26#SPARC_.2832-bit.29>
illustrate that the compat code is *not* namespace-clean at present - too
many functions from different standards all in a single nldbl-compat.o -
though I don't understand how the tests ended up being built using that
compat code in a normal glibc test run.)
--
Joseph S. Myers
joseph@codesourcery.com