Summary: | [cross-mingw32/mingw-runtime] mingw-gcc directory include order problem | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Roberto Castagnola <roberto.castagnola> |
Component: | Current packages | Assignee: | Gentoo Crossdev team <crossdev> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | chris_se, dschridde+gentoobugs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 157997, 627914 | ||
Attachments: |
Patch for toolchain.eclass that fixes this problem
add include_next to some gcc headers |
Description
Roberto Castagnola
2006-12-01 00:55:43 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 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? |