[PATCH] include/bits/*-ldbl.h headers

[PATCH] include/bits/*-ldbl.h headers

[Florian Weimer]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

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?

Thanks,
Florian

[-- Attachment #2: glibc-fedora-include-bits-ldbl.patch --]
[-- Type: text/x-patch, Size: 1062 bytes --]

From 5eb4509a6651d19c7a28c4506d6aa582c9ee095a Mon Sep 17 00:00:00 2001
From: Jakub Jelinek <jakub@redhat.com>
Date: Wed, 1 Feb 2006 09:30:43 +0000
Subject: [PATCH] 128-bit long double fixes

* include/bits/stdlib-ldbl.h: New file.
* include/bits/wchar-ldbl.h: New file.

---
 ChangeLog                  |    5 +++++
 include/bits/stdlib-ldbl.h |    1 +
 include/bits/wchar-ldbl.h  |    1 +
 3 files changed, 7 insertions(+), 0 deletions(-)
 create mode 100644 include/bits/stdlib-ldbl.h
 create mode 100644 include/bits/wchar-ldbl.h

diff --git glibc-2.17-c758a686/include/bits/stdlib-ldbl.h glibc-2.17-c758a686/include/bits/stdlib-ldbl.h
new file mode 100644
index 0000000..6250949
--- /dev/null
+++ glibc-2.17-c758a686/include/bits/stdlib-ldbl.h
@@ -0,0 +1 @@
+#include <stdlib/bits/stdlib-ldbl.h>
diff --git glibc-2.17-c758a686/include/bits/wchar-ldbl.h glibc-2.17-c758a686/include/bits/wchar-ldbl.h
new file mode 100644
index 0000000..29baa2f
--- /dev/null
+++ glibc-2.17-c758a686/include/bits/wchar-ldbl.h
@@ -0,0 +1 @@
+#include <wcsmbs/bits/wchar-ldbl.h>

Re: [PATCH] include/bits/*-ldbl.h headers

[Joseph Myers]

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

Re: [PATCH] include/bits/*-ldbl.h headers

[Florian Weimer]

On 08/24/2017 04:42 PM, Joseph Myers wrote:
> 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).

Thanks for the explanation.  I'm dropping our downstream patch.  We
don't build or test with -mlong-double-64, but perhaps did so at one point.

Florian