Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

On 6/30/18 9:17 AM, Mark Millard wrote:
> On 2018-Jun-30, at 7:51 AM, John Baldwin <jhb at FreeBSD.org> wrote:
> 
>> On 6/29/18 2:37 PM, Mark Millard wrote:
>>> [I expect this is more than just amd64-gcc related but that is all
>>> that ci.freebsd.org normally builds via a devel/*-gcc .]
>>
>> As indicated by my other mail, this is i386 and amd64 specific as it
>> only matters for float.h on i386 due to the disagreement on
>> LDBL_MANT_DIG.
> 
> I was correct about the search order for include files being
> different before -r335782 vs. -r335782 and later:

Yes, but this is kind of a feature, not a bug, and the issue there is that
as much as possible we should allow FreeBSD to work with the standard headers
that are supposed to be part of the language (and thus provided by the
toolchain).  Right now we don't ship any of the 'std*.h' headers clang
provides for example in our base system clang, though a few months ago I
fixed the one place that was using <machine/stdarg.h> instead of
<stdarg.h> in userland that was breaking the use of the toolchain-provided
stdarg.h (both GCC and clang).

> Might this reversal have other effects even for
> architectures for which the code does compile
> via devel/*-gcc ?

It depends on the header.  This particular failure is due to a quirk of
<float.h> on FreeBSD/i386.  I have built other platforms with external
GCC just fine.  To the extent that we encounter any other issues we
should try to make our source more conformant with C and only fall back to
axeing the toolchain-provided language headers as a last resort.

-- 
John Baldwin