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

[Warner Losh]

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

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

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20160331/7079cbce/attachment.sig>