From: SourceForge.net <no...@so...> - 2010-03-17 12:54:44
|
Bugs item #2970986, was opened at 2010-03-16 00:34 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2970986&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tatsuro MATSUOKA (tmacchant) Assigned to: Cesar Strauss (cstrauss) Summary: gcc-4.5.0 problem: compiler cannot find mingwrt headers Initial Comment: Hello This is at first posted to [Mingw-users] list. http://old.nabble.com/gcc-4.5.0-%3A-Is-flag--I-mingw-include-always-needed---td27901832.html Thanks to Earnie and Keith Marshall for your immediate response. Sorry for my bad writing my reports. My phenomena that I met may come from my MinGW is not installed to C:\MinGW but to C:\Programs\MinGW C:\Programs\MinGW has been used for in my favor. (I do not want to make directories in root of the drive if change of the directory position is allow to be moved.) I tried to compile test.c attached on Msys sh shell When MinGW is installed in C:\Programs\MinGW. The result is $ gcc -o test.o test.c test.c:1:19: fatal error: stdio.h: No such file or directory compilation terminated. $ gcc -o test.o test.c -I/mingw/include Msys fstab for mingw c:/Programs/mingw /mingw I moved my MinGW directory from C:\Program\MinGW to C;\MinGW Msys fstab for mingw c:/mingw /mingw This time Tatsu@Shiro ~/program/C/gcctest $ gcc -o test.o test.c worked fine without -I/mingw/include For gcc-3.4.x, gcc-4.4.0, the location of MinGW in not C:\MinGW have been caused no errors from Msys sh shell when Msys fstab for mingw is set like c:/Programs/mingw /mingw Anyway I use at the moment, C:/MinGW instead of C:\Program\MinGW Regards Tatsuro ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2010-03-17 12:54 Message: > [MSYS] *always* converts and canonicalises such patterns, > translating to a native Win32 equivalent Correction: *canonicalisation* doesn't *always* occur by default, but it does for the particular case in point... $ dumpargs \ -DLOCAL_INCLUDE_DIR=\"/mingw/lib/gcc/mingw32/4.5.0/../../../../include\" argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe argv[1]: -DLOCAL_INCLUDE_DIR="d:/usr/mingw-4.5.0/include" ...but... $ dumpargs \ -DLOCAL_INCLUDE_DIR=\"/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../include\" argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe argv[1]: -DLOCAL_INCLUDE_DIR="d:/usr/mingw-4.5.0/bin/../lib/gcc/mingw32/4.5.0/../../../../include" ...an inconsistency which suggests a bug in MSYS' path translation logic. Also, notice the apparent effect of pursuing Earnie's suggestion... $ dumpargs \ -DLOCAL_INCLUDE_DIR=\"//mingw/lib/gcc/mingw32/4.5.0/../../../../include\" argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe argv[1]: -DLOCAL_INCLUDE_DIR="//mingw/lib/gcc/mingw32/4.5.0/../../../../include" ...which leaves the doubled initial slash in place, but... $ dumpargs -DLOCAL_INCLUDE_DIR=\"//mingw\" argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe argv[1]: -DLOCAL_INCLUDE_DIR="/mingw" ...which reduces it; (in this case, it appears that the reduction does not occur when the path extends to a depth of more than one directory)... $ dumpargs -DLOCAL_INCLUDE_DIR=\"//mingw/include\" argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe argv[1]: -DLOCAL_INCLUDE_DIR="//mingw/include" ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2010-03-17 11:19 Message: Cesar, I suggest you use --prefix=//mingw instead. I don't know if either will resolve the problem. The issue may happen at the build once the xgcc compiler stub is in action. You may have to resort to some other trickery but as Keith has said, it would be good to be using our own tools to build our distributions. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-03-17 10:40 Message: > I have identified the issue, as well as a potential fix. Thanks Cesar. This is good news. > I hope to avoid triggering the MSYS path translation by > configuring with --prefix=c:/mingw instead of /mingw. I wonder if this is (partly) the reason why Aaron, and Danny before him, used Cygwin to build their releases. It's good to see that you are building with MSYS -- we should be able to support building on our own platform. > For some reason, it ends-ups being translated by MSYS as: > -DLOCAL_INCLUDE_DIR=\"c:/mingw/include\" The "some reason" would be that MSYS recognises its own emulated Unix path name pattern in the variable assignment, and it *always* converts and canonicalises such patterns, translating to a native Win32 equivalent, when passing such strings either as arguments or in the environment, to a native Win32 application; (the compiler tool chain you are using to bootstrap your build comprises native Win32 applications, as does the tool chain you are building). As a side issue, (for a different ticket, I think), I have been asking for some time, for a mechanism to *selectively* disable MSYS path translation for individual strings -- not a blanket on or off option, as has been tentatively suggested by others, but which I don't believe will be particularly effective. 99.99% of the time, path translation does exactly the right thing, but unfortunately those 0.01% of corner cases where it goes badly wrong represent just too significant a minority, (and unfortunately for the blanket on/off option, they often occur in admixture with examples of the 99.99% majority cases, even within the same command line. ---------------------------------------------------------------------- Comment By: Cesar Strauss (cstrauss) Date: 2010-03-17 04:12 Message: Thanks for the report. I have identified the issue, as well as a potential fix. During the gcc build under MSYS, the Makefile passed the include pathname as: -DLOCAL_INCLUDE_DIR=\"/mingw/lib/gcc/mingw32/4.5.0/../../../..include\" For some reason, it ends-ups being translated by MSYS as: -DLOCAL_INCLUDE_DIR=\"c:/mingw/include\" This interferes with the relocation support. I hope to avoid triggering the MSYS path translation by configuring with --prefix=c:/mingw instead of /mingw. Cesar ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2010-03-16 13:42 Message: I can confirm this as a regression affecting gcc-4.5.0_20100311-1-mingw32; it may not be apparent to those who install with sysroot == c:/mingw, but it is readily observed when an alternative, but equally valid sysroot is chosen, and no prior installation in c:/mingw exists. To reproduce, with parallel installations in d:/usr/MinGW-3.4.5 (GCC-3.4.5) and in d:/usr/MinGW-4.5.0 (GCC-4.5), (and none in C:/MinGW), I have run (under MSYS-1.0.11): $ umount /mingw $ mount d:/usr/mingw-4.5.0 /mingw $ echo '#include <stdio.h>' | gcc -E -o nul -xc - <stdin>:1:19: fatal error: stdio.h: No such file or directory compilation terminated. (The header file is definitely present in the required path): $ ls -l /mingw/include/stdio.h -rw-r--r-- 1 keith ... 22047 Mar 7 03:31 /mingw/include/stdio.h For comparison, the same with GCC-3.4.5: $ umount /mingw $mount d:/usr/mingw-3.4.5 /mingw $ echo '#include <stdio.h>' | gcc -E -o nul -xc - completes silently, (i.e. without error). Repeating the above, with the '-v' option added, reveals the regression; first for the GCC-3.4.5 case: $ echo '#include <stdio.h>' | gcc -v -E -o nul -xc - Reading specs from d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) d:/usr/mingw-3.4.5/bin/../libexec/gcc/mingw32/3.4.5/cc1.exe -E -quiet -v -iprefix d:\usr\mingw-3.4.5\bin\../lib/gcc/mingw32/3.4.5/ -Id:/usr/local/include - -o nul.exe ignoring nonexistent directory "d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/include" ignoring nonexistent directory "/mingw/include" ignoring nonexistent directory "/mingw/include" ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.5/include" ignoring nonexistent directory "/mingw/mingw32/include" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: d:/usr/local/include d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/include End of search list. Ignoring the addition of d:/usr/local/include to the include search path, (I add it using a local specs file customisation), that all seems as it should be; mingwrt header files are found on the second path, d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include, (which simplifies to d:/usr/mingw-3.4.5/include, the standard installation path for these headers, with a sysroot == d:/usr/mingw-3.4.5). Repeating for the GCC-4.5.0 case: $ umount /mingw $ mount d:/usr/mingw-4.5.0 /mingw $ echo '#include <stdio.h>' | gcc -v -E -o nul -xc - Using built-in specs. COLLECT_GCC=d:\usr\mingw-4.5.0\bin\gcc.exe COLLECT_LTO_WRAPPER=d:/usr/mingw-4.5.0/bin/../libexec/gcc/mingw32/4.5.0 /lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.0_20100311/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 --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.0 20100311 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-E' '-o' 'nul' '-mtune=i386' '-march=i386' d:/usr/mingw-4.5.0/bin/../libexec/gcc/mingw32/4.5.0/cc1.exe -E -quiet -v -iprefix d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/ - -o nul -mtune=i386 -march=i386 ignoring nonexistent directory "c:/mingw/include" ignoring nonexistent directory "/mingw/include" ignoring duplicate directory "d:/usr/mingw-4.5.0/lib/gcc/../../lib/gcc/mingw32/4.5.0/include" ignoring duplicate directory "d:/usr/mingw-4.5.0/lib/gcc/../../lib/gcc/mingw32/4.5.0/include-fixed" ignoring nonexistent directory "d:/usr/mingw-4.5.0/lib/gcc/../../mingw32/include" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include-fixed End of search list. <stdin>:1:19: fatal error: stdio.h: No such file or directory compilation terminated. gcc.exe: nul: Permission denied Note the hard coded addition of the non-existent c:/mingw/include directory to the include search path; the presence of this is, in itself and IMO, an error, which explains why those with sysroot == c:/mingw may not notice the regression. On its own, this error is innocuous; the regression is that the required <sysroot>/bin/../lib/gcc/mingw32/3.4.5/../../../../include has been omitted, (perhaps having been unintentionally replaced by the hard coded c:/mingw/include, but I offer no evidence to support this hypothesis). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2970986&group_id=2435 |