Fwd: Re: gcc46 header search path
Andriy Gapon
avg at FreeBSD.org
Fri Jul 6 12:34:30 UTC 2012
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
More information about the freebsd-toolchain
mailing list