Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric <dim_at_freebsd.org> wrote:

> On 01 Apr 2016, at 00:44, Warner Losh <imp_at_bsdimp.com> wrote:
> >
> >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrewery_at_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.

Warner