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?
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
umm, no ... gcc headers should always be read before anything from the libc (mingw-runtime in this case)
(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
Is this still valid? I thought it got fixed upstream a while ago...
(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.
This really is an upstream issue, right? Was a bug reported there?
(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.
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.
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 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
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
Is this still an issue?
