This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]