gcc46 header search path

Warner Losh imp at bsdimp.com
Fri Jul 6 16:21:05 UTC 2012


On Jul 6, 2012, at 9:14 AM, Andriy Gapon wrote:

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

I didn't, because I know the standard behavior.  Turns out, I don't know today's standard behavior, just the historical behavior of gcc, which has changed over the life of FreeBSD.

FreeBSD's standard compiler has never included it.  There was talk about 10 years ago about adding it, but it was shouted down as a stupid idea.  I tend to agree, but I can't articulate good reasons.

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 <avg at 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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe at freebsd.org"
>> 
> 
> 
> -- 
> Andriy Gapon
> 
> 



More information about the freebsd-toolchain mailing list