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

[Dimitry Andric]

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... :)


>> 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.

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.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20160401/056502c1/attachment.sig>