Top posting, because I'm lame... I think it shouldn't be there. It is non-standard behavior both in the gcc world and in the freebsd world. It does save a little on makefiles on some ports, but most ports already grok things are in /usr/local or opt/local and cope.
Warner On Jul 6, 2012, at 6:34 AM, Andriy Gapon wrote: > > Inviting wider audience to the discussion. > > -------- Original Message -------- > Date: Fri, 06 Jul 2012 00:43:58 +0300 > From: Andriy Gapon <a...@freebsd.org> > Subject: Re: gcc46 header search path > > on 05/07/2012 17:15 Andriy Gapon said the following: >> >> Gerald, >> >> while thinking what to reply in our other conversation I ran into another >> issue >> with gcc46: >> >> $ echo "" | cpp46 -v >> [trim] >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd10.0/4.6.3/include >> /usr/local/include >> /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd10.0/4.6.3/include-fixed >> /usr/include >> End of search list. >> [trim] >> >> I don't think that /usr/local/include should automagically appear in the >> search >> list. Base gcc doesn't have it and there doesn't seem to be a good reason to >> include "arbitrary" non-system directory into the default search path. >> > > On the other hand the above seems to match the default upstream behavior as > described here: http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html > It's understandable that such a difference between the base gcc compiler and > gcc > compilers from ports introduces subtle issues to ports. > > I am now confused and torn as to which behavior should be preferable. > On one hand it's easier to patch the port gcc-s to match the base one. > On the other hand the default gcc behavior would save many lines in port > makefiles that explicitly add -I ${LOCALBASE}/include or some such to CFLAGS. > buildworld and buildkernel (and etc) could be spared from any interference > from > /usr/local by using -nostdinc and explicitly setting all necessary include > paths. > > Adding more people to conversation in hope that it could become fruitful. > > > -- > Andriy Gapon > > > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
