This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] include/bits/*-ldbl.h headers
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 24 Aug 2017 16:54:33 +0200
- Subject: Re: [PATCH] include/bits/*-ldbl.h headers
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 62B4D81DF3
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com>
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.