From: Keith M. <kei...@us...> - 2012-02-14 20:01:54
|
On 13/02/12 19:45, Earnie Boyd wrote: > On Mon, Feb 13, 2012 at 12:28 PM, Eli Zaretskii <eliz@...> wrote: >>> Date: Mon, 13 Feb 2012 07:46:24 -0500 >>> From: Earnie Boyd <earnie@...> >>> >>>> I'm compiling a C program that sets floating point control word: >>>> >>>> <test.c> >>>> #include <float.h> >>>> >>> >>> This is c:/mingw/lib/gcc/[GCC-VERSION]/mingw32/include/float.h which >>> isn't kind enough to ``#include_next <float.h>'' >> >> Shouldn't it be the other way around? That is, shouldn't MinGW header >> #include_next the one from GCC? > > It does already. The issue is that GCC has a regression that chooses > its library header first. And, at least up to (and including) GCC-3.4.5, the MinGW header did appear first in the #include search path, so all was hunky-dory. >> At least on my machine (which uses such an ancient version of GCC that >> I'm embarrassed to say which one) this is so. > > Yes, it used to work just fine. IIRC, Keith told me that GCC used to > do what I suggested above. I can't find the reference to what I'm > think of though. http://bit.ly/xK7fyY perhaps? Reviewing that today, I can no longer reproduce the fault with my self built GCC-3.4.5 cross-compiler, (on LinuxMint-10): $ mingw32-gcc -v -c -o /dev/null -xc /dev/null Reading specs from /home/keith/mingw32/lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5-20060117-2/configure --prefix=/home/keith/mingw32 --target=mingw32 --with-gcc --with-gnu-as --with-gnu-ld --disable-nls --disable-shared --disable-debug --enable-threads=win32 --disable-win32-registry --enable-sjlj-exceptions --with-sysroot=/home/keith/mingw32 --enable-languages=c,c++,f77 Thread model: win32 gcc version 3.4.5 (mingw-vista special r2) /home/keith/mingw32/libexec/gcc/mingw32/3.4.5/cc1 -quiet -v -isystem /home/keith/mingw32-local/include /dev/null -quiet -dumpbase null -auxbase-strip /dev/null -version -o /tmp/ccUDD3Ar.s ignoring nonexistent directory "/home/keith/mingw32/lib/gcc/mingw32 /3.4.5/../../../../mingw32/include" ignoring nonexistent directory "/home/keith/mingw32/mingw/include" #include "..." search starts here: #include <...> search starts here: /home/keith/mingw32-local/include /home/keith/mingw32/usr/local/include /home/keith/mingw32/lib/gcc/mingw32/3.4.5/include End of search list. GNU C version 3.4.5 (mingw-vista special r2) (mingw32) compiled by GNU C version 4.4.5. GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62529 ... Note the order of the header searches: 1) /home/keith/mingw32-local/include This is established by a local specs file customisation; it's where I put the add-on headers I install, so they are kept separate from the MinGW and GCC core header sets. 2) /home/keith/mingw32/usr/local/include This is the sysroot path, (from --with-sysroot=/home/keith/mingw32); it is where MinGW's headers (including float.h) are installed. 3) /home/keith/mingw32/lib/gcc/mingw32/3.4.5/include This is where the GCC specific headers are installed; hence the GCC float.h is correctly pulled in, by #include_next, from (2). However, with GCC-4.6.2 on my MSYS box, I see: $ gcc -v -c nul.c Using built-in specs. COLLECT_GCC=C:/mingw32/bin/gcc.exe COLLECT_LTO_WRAPPER=c:/mingw32/bin/../libexec/gcc/mingw32/4.6.2 /lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.6.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386' c:/mingw32/bin/../libexec/gcc/mingw32/4.6.2/cc1.exe -quiet -v -iprefix c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/ nul.c -quiet -dumpbase nul.c -mtune=i386 -march=i386 -auxbase nul -version -o C:/Users/.../AppData/Local/Temp/ccsEB0ea.s GNU C (GCC) version 4.6.2 (mingw32) compiled by GNU C version 4.6.2, GMP version 5.0.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "c:/mingw32/bin/../lib/gcc/mingw32 /4.6.2/../../../../mingw32/include" ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32 /4.6.2/include" ignoring nonexistent directory "/mingw/include" ignoring duplicate directory "c:/mingw32/lib/gcc/../../include" ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32 /4.6.2/include-fixed" ignoring nonexistent directory "c:/mingw32/lib/gcc/../../lib/gcc /mingw32/4.6.2/../../../../mingw32/include" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/include c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/../../../../include c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/include-fixed End of search list. ... Note that, in this case, the search order is: 1) c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/include This is equivalent to c:/mingw32/lib/gcc/mingw32/4.6.2/include; it is the GCC specific headers directory, in which GCC's float.h is found. 2) c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/../../../../include This is equivalent to c:/mingw32/include, which is the MinGW headers directory; note that it is now placed *after* the GCC directory, so its float.h is occluded by the GCC version, (which does not #include_next this, nor any other supplementary float.h); this is the GCC regression to which Earnie refers. 3) c:/mingw32/bin/../lib/gcc/mingw32/4.6.2/include-fixed This is a further GCC include directory, (for headers with applied fix-ups); its presence here is not germane to the issue. On the original patch ticket, I invited Aaron, Danny, or Cesar to pursue this with the GCC folks. Has it been expedited? I don't know, and I simply don't have the time to follow it up, but *somebody* needs to pick up this ball, and run with it. -- Regards, Keith. |