Bug 156767 – [cross-mingw32/mingw-runtime] mingw-gcc directory include order problem

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Roberto Castagnola 2006-12-01 00:55:43 UTC]

running mingw-gcc -v test.c I get this directory include order:

ignoring nonexistent directory "/usr/mingw32/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/mingw32/3.4.6/../../../../mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/mingw32/3.4.6/include
 /usr/mingw32/mingw/include
End of search list.

The problem is that /usr/mingw32/mingw/include/float.h (containing #include_next<float.h> and extending gcc header) should be read before /usr/lib/gcc/mingw32/3.4.6/include/float.h
On the other hand, I think /usr/lib/gcc/mingw32/3.4.6/include/limits.h should be read before /usr/mingw32/mingw/include/limits.h

How it can be fixed?

[Comment 1 Roberto Castagnola 2006-12-01 11:07:25 UTC]

Since /usr/mingw32/usr/local/include is checked before /usr/lib/gcc/mingw32/3.4.6/include, it could be solved with a symlink:

/usr/mingw32/usr/local/include/float.h -> ../../include/float.h

[Comment 2 SpanKY 2006-12-01 18:31:21 UTC]

umm, no ... gcc headers should always be read before anything from the libc (mingw-runtime in this case)

[Comment 3 Roberto Castagnola 2006-12-02 00:07:48 UTC]

(In reply to comment #2)

But the symlink I proposed is only for mingw-runtime float.h header (containing #include_next<float.h> at his top so gcc float.h header is included first). Other mingw-runtime headers will be read after gcc headers

[Comment 4 Dennis Schridde 2008-01-15 18:43:58 UTC]

Is this still valid? I thought it got fixed upstream a while ago...

[Comment 5 Roberto Castagnola 2008-01-15 22:09:46 UTC]

(In reply to comment #4)
> Is this still valid? I thought it got fixed upstream a while ago...

Still valid with mingw-runtime-3.13 in portage tree.

[Comment 6 Dennis Schridde 2008-01-15 23:29:05 UTC]

This really is an upstream issue, right? Was a bug reported there?

[Comment 7 Roberto Castagnola 2008-01-16 13:02:21 UTC]

(In reply to comment #6)
> This really is an upstream issue, right? Was a bug reported there?

It seems to me that upstream consider mingw-runtime headers to be read first. For this reason I opened a gentoo bug and I never reported this to upstream.

[Comment 8 Christian Seiler 2009-03-23 19:43:42 UTC]

Created attachment 186032 [details, diff]
Patch for toolchain.eclass that fixes this problem

I've stumbled across this problem too and created a patch for toolchain.eclass that works for me with i686-mingw32 target and gcc 4.3.3.

[Comment 9 Christian Seiler 2009-11-06 17:55:29 UTC]

Any comments on this? It's been ten months since I posted a very simple solution for this bug... If there are some technical objections to the patch I'd be glad to help resolve them. But I'd really like to see this fixed in portage.

[Comment 10 SpanKY 2010-06-20 04:13:21 UTC]

Comment on attachment 186032 [details, diff]
Patch for toolchain.eclass that fixes this problem

we're not going to mess with the local prefix on a per-target basis

wonder if the different order is due to sysroot usage

[Comment 11 Roberto Castagnola 2011-02-20 22:59:16 UTC]

Created attachment 263225 [details, diff]
add include_next to some gcc headers

Same issue with mingw64-runtime.
I have found a patch for it here [1]; I think it should be safe to apply.
To use the same approach with mingw-runtime, floath.h from it should be patched to remove #include_next<float.h>, as suggested here [2].

I'm using attached patch with following packages:
cross-i686-w64-mingw32/gcc-4.5.2
cross-i686-w64-mingw32/mingw64-runtime-20101003


[1] http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01114.html
[2] http://sourceforge.net/tracker/?func=detail&atid=302435&aid=3011968&group_id=2435

[Comment 12 Sergei Trofimovich (RETIRED) 2018-04-07 12:22:48 UTC]

Is this still an issue?