Date: Fri, 06 Jul 2012 18:14:23 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: toolchain@FreeBSD.org Subject: Re: gcc46 header search path Message-ID: <4FF700CF.2000206@FreeBSD.org> In-Reply-To: <508B8B4E-DF5E-412B-BD2B-86F21EBF4C8C@bsdimp.com> References: <4FF60A9E.5070503@FreeBSD.org> <4FF6DB51.40904@FreeBSD.org> <508B8B4E-DF5E-412B-BD2B-86F21EBF4C8C@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 06/07/2012 18:10 Warner Losh said the following: > 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. Please define the non-standard behavior. Just curious if you opened the link. > 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 <avg@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-unsubscribe@freebsd.org" > -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FF700CF.2000206>