Date: Fri, 1 Apr 2016 08:25:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Dimitry Andric <dim@freebsd.org> Cc: Bryan Drewery <bdrewery@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Gerald Pfeifer <gerald@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Mark Millard <markmi@dsl-only.net> Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) Message-ID: <CANCZdfoa3kth8USvLXXrzAO5KgbizN29WCj4ebb02=Nj75ZU6A@mail.gmail.com> In-Reply-To: <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <DD2A166A-28D3-4F97-A084-6109B0BA21CC@bsdimp.com> <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric <dim@freebsd.org> wrote: > On 01 Apr 2016, at 00:44, Warner Losh <imp@bsdimp.com> wrote: > > > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrewery@freebsd.org> > wrote: > >> I didn't realize the ports compiler was defaulting /usr/local/include > >> into the search path now. It does not have /usr/local/lib in the > >> default library path as far as I can tell. It's also broken for its > >> -rpath (noted in its pkg-message). So having a default > >> /usr/local/include path seems odd. > > > > It has for a while now. It=E2=80=99s one of the maddening inconsistenci= es that > abound in this > > area. I took a poll a while ago and there seemed to be widespread > support for adding > > it to the base compiler. > > This was the main reason /usr/local/include was *not* included in the > base compiler, otherwise it would unpredictably pick up headers in > /usr/local/include during builds. You can never know which conflicting > headers a certain user has installed in /usr/local/include... :) That's why it shouldn't be *FIRST*, not why it shouldn't be there at all. >> Adding -isystem /usr/include to fix this is probably possible but > >> there's a risk someone will remove it as redundant. In this case I wi= sh > >> /usr/include was first but I'm not sure what impact that would have on > >> consumers expecting /usr/local/include (and /usr/local/lib) overrides = to > >> work, though they would need to pass a -L /usr/local/lib anyhow and > >> would likely be passing -I /usr/local/lib too. > > > > /usr/include should be first. But it isn=E2=80=99t. That=E2=80=99s anot= her inconsistency > that was found > > when we looked at /usr/local stuff. Someone recently added > /usr/local/bin to the path, > > if I recall correctly. > > Isn't that a bit of a bikeshed? I guess some people would just as well > prefer /usr/local/include to be first, just like some people prefer > /usr/local/bin before /usr/bin in their PATH. > Sigh. No. /usr/local is moving into many different things in the base and ports. We should do it in a consistent way. What we have now is not consistent and somewhat brittle. > In any case, if such paths are added to external compilers, we better > make sure almost everything in buildworld uses -nostdinc, and specifying > exactly the include directories we need, and no others. Cumbersome, but > maybe for a good cause. That's the non-brittle solution here. An over-reliance on defaults makes it difficult to ensure other compilers will work, especially ones we don't tightly control the defaults for. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoa3kth8USvLXXrzAO5KgbizN29WCj4ebb02=Nj75ZU6A>