This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch win32]: fix for PR target/41943
On Fri, 23 Jul 2010, Richard Guenther wrote:
> > Err.. I'm not sure quite what you're talking about.
> >
> > native:
> > #include "..." search starts here:
> > #include <...> search starts here:
> > ?/usr/local/include
> > ?/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
> > ?/usr/include
> > End of search list.
> >
> > cross+sysroot:
> > #include "..." search starts here:
> > #include <...> search starts here:
> > ?/local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include
> > ?/local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include-fixed
> > ?/local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/../../../../alphaev67-linux/include
> > ?/local/rth/gcc/run-axp/alphaev67-linux/sys-root/usr/include
> > End of search list.
> >
> > In both cases gcc-include preceeds the system-include dir.
> > The only difference is that native also searches local-include
> > (although I can't tell you why that preceeds gcc-include).
>
> I wondered about this myself, but it is even documented this way
> in cpp.texi ...
>
> It seems that there is no local include dir for cross+sysroot.
>
> I'm sure Joseph knows why?
My guess would be that the ordering predates the separation of include and
include-fixed. /usr/local/include was meant to be headers that are known
to work with GCC (as opposed to /usr/include, the headers originally for
use with a proprietary non-GNU compiler) and so (a) didn't need fixed
versions of headers and (b) was meant to go before system headers and
override them in the case of local GNU libraries replacing pieces of
system functionality.
Now, I'd think what's logical would be the GCC include directory, then
system headers including both /usr/local/include and /usr/include and
putting fixed versions of a directory immediately before that directory.
But since we only have fixed headers for /usr/include, that means include,
/usr/local/include, include-fixed, /usr/include. In a sysroot
configuration, $sysroot/usr/local/include ought to be searched; I see no
reason for it not to be and searching it improves consistency with what is
searched in the native case.
--
Joseph S. Myers
joseph@codesourcery.com