On 2018-Jun-30, at 9:29 AM, John Baldwin <jhb at FreeBSD.org> wrote: > 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. It is too bad that the review https://reviews.freebsd.org/D16055 did not catch the change in what headers are used by buildworld and buildkernel. I'd view such switching of long established header bindings as a fairly big deal, possibly even warranting being explicitly proposed and debated. I'm not claiming my opinion on which search order that I have is actually relevant. I'm just now nervous about my powerpc64-gcc based builds having unexpected differences, for example. [I sometimes explore the status of powerpc family builds via more modern toolchains.] (But lib32 for powerpc64 via modern gcc's is messed up anyway, generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about that.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Sat Jun 30 2018 - 15:05:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC