This is the mail archive of the
mailing list for the GCC project.
Re: [patch win32]: fix for PR target/41943
On 07/22/2010 02:19 PM, Kai Tietz wrote:
> 2010/7/22 Richard Henderson <email@example.com>:
>> On 07/22/2010 01:36 PM, Kai Tietz wrote:
>>> the headers aren't the issue. As you see they are working nicely with
>>> native compilers (see Danny's comment). But the flaw begins with
>>> sysroot and cross-compilers, as here suddenly the internal gcc-headers
>>> simply override the system-headers (to mark this explicit: not for
>>> native). So this means that the gcc headers would be in need to know,
>>> if they are used by native toolchain and therefore don't have to
>>> forward, or if they are part of a sysrooted or a cross-compiler
>>> toolchain, where they need to do this.
>>> So I heard now pretty often that to change cross-compiler/sysroot
>>> include order here is a flaw. But I would really like to know what is
>>> the reason for the current behavior (not a meaning, a reason please)
>>> especially in respect to native/cross.
>> Err.. I'm not sure quite what you're talking about.
> Thank you posting it. Here I can exactly show what we mean and what
> cause us troubles.
>> #include "..." search starts here:
>> #include <...> search starts here:
> ^^^^^^ Here you have your system-header location before the gcc
> include (line below)
>> End of search list.
And here is the source of confusion.
/usr/local/include = local-include
/usr/lib/gcc/**/include = gcc-include
/usr/include = system-include.
So your statement above is false -- or at least not strictly accurate -- and
implies that yall are installing your system headers into the wrong directory.