[patch win32]: fix for PR target/41943

[Kai Tietz]

2010/7/22 Richard Henderson <rth@redhat.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.

> native:
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
^^^^^^ Here you have your system-header location before the gcc
include (line below)
>  /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
^^^^ Here as you see comes the gcc include folder first.
>  /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).
>
> Are you guys installing stuff in local-include by default,
> rather than a system-include path?

I don't get you for cross?

As you can see easily is (as example) the header 'float.h' taken from
'/usr/local/include' and then - if not found or by include_next' from
'/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include'.

For cross-compiler it will be always taken from
'/local/rth/gcc/run-axp/lib/gcc/alphaev67-linux/4.6.0/include' and the
other system-directories will be never searched.

This is exactly the difference which makes us troubles, that for cross
the behavior of gcc is different then it is possible for an native
compiler.

Regards,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination