From: dave b. <dav...@gm...> - 2006-10-23 21:24:23
|
Hi After narrowing down my problem, it seems that the include search order in my gcc 4.1.1 pick the wrong file by looking in this directory first: c:/mingw/bin/../lib/gcc/mingw32/4.1.1/include instead of this one: C:/MinGW/include Which result in the wrong headers being compiled. (I'm using mingw in windows) How can I fix that? dave |
From: Michael G. <mg...@te...> - 2006-10-24 11:28:57
|
> After narrowing down my problem, it seems that the include search > order in my gcc 4.1.1 pick the wrong file by looking in this directory > first: > c:/mingw/bin/../lib/gcc/mingw32/4.1.1/include > instead of this one: > C:/MinGW/include > Which result in the wrong headers being compiled. > (I'm using mingw in windows) >=20 > How can I fix that? I don't know how to fix that but I know my linuxhosted mingw xcompiler does suffer from the same problem. =46WIW the stock version provided on mingw.org does *NOT* have this problem but does indeed search C:/MinGW/include (or however it is installed) first. Thus said I two QnD workarounds: =2D use the stock version (gcc 3.4.5 IIRC) =2D meddle with the include directories of your installation (use with care as it might break things). Oh, BTW, if you find a proper solution that changes the include searchorder I'd be grateful if you could post it here. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Earnie B. <ea...@us...> - 2006-10-24 11:33:36
|
Quoting dave berk <dav...@gm...>: > Hi > > After narrowing down my problem, it seems that the include search > order in my gcc 4.1.1 pick the wrong file by looking in this directory > first: You don't say what header you're using. > c:/mingw/bin/../lib/gcc/mingw32/4.1.1/include That is a viable search path, what header? > instead of this one: > C:/MinGW/include That is a viable search path, what header? > Which result in the wrong headers being compiled. > (I'm using mingw in windows) > > How can I fix that? > What is the output of ``gcc -v''? Earnie Boyd -- -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Easy Blogger Creator: <a href="http://give-me-an-offer.com/1006/">Offer 1006</a> 4 Seasons Wine - Buy 6, Get 6 Free <a href="http://give-me-an-offer.com/1007/">Offer 1007</a> |
From: Keith M. <kei...@to...> - 2006-10-24 14:21:16
|
Earnie Boyd wrote, quoting Dave Berk: >> After narrowing down my problem, it seems that the include search >> order in my gcc 4.1.1 pick the wrong file by looking in this directory >> first: > > You don't say what header you're using. IIRC, the OP reported problems which appeared to be the result of using an inappropriate float.h. >> c:/mingw/bin/../lib/gcc/mingw32/4.1.1/include > > That is a viable search path, what header? > >> instead of this one: >> C:/MinGW/include Michael Gerdau wrote: > I don't know how to fix that but I know my linux hosted mingw > xcompiler does suffer from the same problem. Mine too, it would seem: (long path names folded at `/<fold>'): keith@ubuntu:~/sandbox/mingw/xscripts$ i586-mingw32-gcc -v -c foo.c Reading specs from /home/keith/mingw/lib/gcc/i586-mingw32/3.4.5/specs Configured with: ../gcc-3.4.5-20060117-1/configure --prefix=/home/keith/mingw --target=i586-mingw32 --enable-languages=c,c++,f77 --enable-threads --disable-win32-registry --disable-nls Thread model: win32 gcc version 3.4.5 (mingw special) /home/keith/mingw/libexec/gcc/i586-mingw32/3.4.5/cc1 -quiet -v foo.c -quiet -dumpbase foo.c -mtune=pentium -auxbase foo -version -o /tmp/ccDr0M7e.s ignoring nonexistent directory "/home/keith/mingw/lib/gcc/<fold> i586-mingw32/3.4.5/../../../../i586-mingw32/sys-include" #include "..." search starts here: #include <...> search starts here: /home/keith/mingw/lib/gcc/i586-mingw32/3.4.5/include /home/keith/mingw/lib/gcc/i586-mingw32/3.4.5/../../../../<fold> i586-mingw32/include End of search list. GNU C version 3.4.5 (mingw special) (i586-mingw32) compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5). GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63516 /home/keith/mingw/lib/gcc/i586-mingw32/3.4.5/../../../../<fold> i586-mingw32/bin/as -o hello.o /tmp/ccDr0M7e.s Brian Dessent wrote, quoting Michael's same post: >> FWIW the stock version provided on mingw.org does *NOT* have >> this problem but does indeed search C:/MinGW/include (or however >> it is installed) first. > > There are two main things that would cause this difference, one being > that there are numerous and extensive changes between 3.x and 4.x; the > second being that the gcc binaries on mingw.org/sourceforge.net contain > local patches not included in the upstream, and one of them may be > fixing this. It would be worth glancing at the patches to see if this > is the case. Hmm. My i586-mingw32-gcc *is* built from the MinGW sources, as found at `http://sourceforge.net/project/showfiles.php?group_id=2435', and, AFAIK, these *should* have any necessary MinGW patches already applied, so that clearly doesn't explain the undesirable search order. Also, my i586-mingw32-gcc is *identically* the same version as that which is currently distributed as the stock binary for Win32, so neither can differences between 3.x and 4.x explain the anomaly. Like Michael, I too would like to understand what is different between Danny's native build, and our cross hosted build, so that we can avoid the contamination of our installed tree by stock GCC headers, which may not be appropriate for MinGW use, yet which precede the correct MinGW headers, in the compiler's include path. Regards, Keith. |
From: dave b. <dav...@gm...> - 2006-10-24 18:09:20
|
I'm at work now so I can't run gcc -v. will run at home. What happen tthough is that the gcc first goes to c:/mingw/bin/../lib/gcc/mingw32/4.1.1/include where it finds the gcc float header while this directory C:/MinGW/include host the mingw (i think) float header, which calls the gcc float header using include_next. so by finding c:/mingw/bin/../lib/gcc/mingw32/4.1.1/include first, gcc doesn't get to read the other float header. my gcc 4.1.1 is compiled for mingw, and i'm using the mingw packages from mingw.org apart from the gcc itself. as to the patches, where can I find them? thanks dave |
From: Earnie B. <ea...@us...> - 2006-10-24 18:26:29
|
Quoting Keith MARSHALL <kei...@to...>: > > Like Michael, I too would like to understand what is different between > Danny's native build, and our cross hosted build, so that we can avoid > the contamination of our installed tree by stock GCC headers, which may > not be appropriate for MinGW use, yet which precede the correct MinGW > headers, in the compiler's include path. > On the cross build the machine specific target headers are included first and they are stored in the lib/gcc-lib path. The issue seems to me to be that the machine specific float.h at build time is incorrect and needs to be updated to simply include the mingw version. Earnie Boyd -- -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Easy Blogger Creator: <a href="http://give-me-an-offer.com/1006/">Offer 1006</a> 4 Seasons Wine - Buy 6, Get 6 Free <a href="http://give-me-an-offer.com/1007/">Offer 1007</a> |
From: Brian D. <br...@de...> - 2006-10-24 11:35:33
|
Michael Gerdau wrote: > FWIW the stock version provided on mingw.org does *NOT* have > this problem but does indeed search C:/MinGW/include (or however > it is installed) first. There are two main things that would cause this difference, one being that there are numerous and extensive changes between 3.x and 4.x; the second being that the gcc binaries on mingw.org/sourceforge.net contain local patches not included in the upstream, and one of them may be fixing this. It would be worth glancing at the patches to see if this is the case. Brian |
From: Michael G. <mg...@te...> - 2006-10-25 07:13:51
|
> > FWIW the stock version provided on mingw.org does *NOT* have > > this problem but does indeed search C:/MinGW/include (or however > > it is installed) first. >=20 > There are two main things that would cause this difference, one being > that there are numerous and extensive changes between 3.x and 4.x; the > second being that the gcc binaries on mingw.org/sourceforge.net contain > local patches not included in the upstream, and one of them may be > fixing this. It would be worth glancing at the patches to see if this > is the case. Neither of it seems the cause because: =2D my linux hosted xcompiler suffers from it even when I build it from the already patched srcs of gcc 3.4.5 as downloaded from mingw.org (i.e. no 3.x/4.x issue) =2D one of the things I had investigated while trying to find a fix to this problem (for the xcompiler) was comparing the patchset against mainstream. There is nothing in it that fixes this, at least not directly (or I'm just not clever enough to spot it; but then since the version build from the patched srcs...). I haven't looked into it for some time now but IIRC the cause for the xcompiler was related to [not] properly (or so) detecting the usr-local include path of the target environment. It is my impression this works slightly different in a cygwin shell than on my linux box in the xcompiling case. Unfortunately I have not yet been able to solve it (other than copying files around). Those interested might want to search the archives as there had been extensive discussions on this problem (again triggered by the "wrong" float.h being included first (i.e. basically the same problem as the OP of this thread had been experiencing). I *suspect* it should be fixable by applying a patch to configure (or configure.in) of gcc and add something to the xcompiling that's in the native cygwin branch as well. If anyone wishes to tacle this I'm happy to provide detailed logs of the xcompiler-generating process as well as test out patches. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |