On 01 Apr 2016, at 00:44, Warner Losh <i...@bsdimp.com> wrote: > >> 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.
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
Description: Message signed with OpenPGP using GPGMail