gcc46 header search path

[Andriy Gapon]

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