include/bits/*-ldbl.h headers

  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
  

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.)
  

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