Re: [Mingw-w64-public] Include paths, float.h

[NightStrike <nig...@gm...>]

On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz <kti...@go...> wrote:
> 2010/3/23 NightStrike <nig...@gm...>:
>> On Tue, Mar 23, 2010 at 12:57 AM, Mook
>> <moo...@gm...> wrote:
>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike <nig...@gm...> wrote:
>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer <se...@gm...> wrote:
>>>>> For some reason yet unknown to me, the gcc-provided headers
>>>>> have priority over the system provided headers and float.h is
>>>>> especially problematic: Not installing or deleting it is the solution,
>>>>> at least for now.
>>>>
>>>> If gcc headers didn't take priority, then fixincludes wouldn't work.
>>>>
>>>> The real question is why gcc forces changes to system headers instead
>>>> of working with system headers.
>>>
>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't
>>> been able to come up with a patch that I don't hate yet.  If something
>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in
>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have
>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot
>>> prefix builds, so that's not useful.
>>>
>>> Mostly sending this just so the mailing list archive can help remember
>>> this for me ;)
>>>
>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44
>>>
>>> --
>>> Mook
>>>
>>
>> The real fix is to sync what gcc wants with what we have, with
>> appropriate changes on both sides.
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Mingw-w64-public mailing list
>> Min...@li...
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
> We (Ozkan and I) already tried to push necessary changes to gcc. But
> well, people love their POSIX stuff and dislike even an include next
> here. Problem is also that mingw.org don't provide those headers in
> their CRT at all, so a change here as to be runtime-specific, which
> messes things a bit (include of _mingw.h and checking for runtime).
> Best solution is (as work-around) to remove those headers from gcc's
> /lib/gcc/<target>/<version>/include directory

That's hardly "best".  We need to try again, and get GCC to listen.

I don't care about mingw.org... we can do something vendor-specific
for that.  But I do care about having GCC do a fixincludes on our
headers, that we then revert.  That's just plain stupid.

Who's the GCC maintainer that we need to hit over the head?