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>
index | next in thread | previous in thread | raw e-mail
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’s one of the maddening inconsistencies 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 wish > >> /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’t. That’s another 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. Warnerhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoa3kth8USvLXXrzAO5KgbizN29WCj4ebb02=Nj75ZU6A>