> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrew...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
