I currently use MinGW gcc 3.3 crossed over from i686-pc-linux-gnu. It lives in C:\MinGW. If I compile a Hello World program with g++ -v, it says (in part): ignoring nonexistent directory "C:/MinGW/mingw32/include" ignoring nonexistent directory "/home/stl/temp/dest/include/c++/3.3" ignoring nonexistent directory "/home/stl/temp/dest/include/c++/3.3/mingw32" ignoring nonexistent directory "/home/stl/temp/dest/include/c++/3.3/backward" ignoring nonexistent directory "/home/stl/temp/dest/include" ignoring nonexistent directory "/home/stl/temp/dest/include" ignoring nonexistent directory "/home/stl/temp/dest/lib/gcc- lib/mingw32/3.3/include" ignoring nonexistent directory "/home/stl/temp/dest/mingw32/include" ignoring nonexistent directory "/usr/local/mingw32/include" #include "..." search starts here: #include <...> search starts here: C:/MinGW/include/c++/3.3 C:/MinGW/include/c++/3.3/mingw32 C:/MinGW/include/c++/3.3/backward C:/MinGW/include C:/MinGW/lib/gcc-lib/mingw32/3.3/include End of search list. It produces a hello.exe that works. I bootstrapped 3.3.3 in MinGW/MSYS. I put it in C:\Temp\gcc\gcc-3.3.3-meow. It says: ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3.3" ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3.3/i686-pc- mingw32" ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3.3/backward" ignoring nonexistent directory "c:/temp/gcc/dest/include" ignoring nonexistent directory "/c/temp/gcc/dest/include" ignoring nonexistent directory "c:/temp/gcc/dest/lib/gcc-lib/i686-pc- mingw32/3.3.3/include" ignoring nonexistent directory "c:/temp/gcc/dest/i686-pc-mingw32/include" #include "..." search starts here: #include <...> search starts here: C:/Temp/gcc/gcc-3.3.3-meow/lib/gcc-lib/i686-pc-mingw32/3.3.3/include /mingw/include End of search list. It then fails to find <iostream>. All of the MinGW/MSYS bootstrapped gcc's I've been accumulating - 3.3, 3.3.1, 3.3.3, and 3.4-20040310 with the PR12974 and PR14291 patches - have this same problem. 3.3 living in C:\Temp\gcc\gcc-3.3-hiss says: ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3" ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3/i686-pc- mingw32" ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3/backward" ignoring nonexistent directory "c:/temp/gcc/dest/include" ignoring nonexistent directory "/c/temp/gcc/dest/include" ignoring nonexistent directory "c:/temp/gcc/dest/lib/gcc-lib/i686-pc- mingw32/3.3/include" ignoring nonexistent directory "c:/temp/gcc/dest/i686-pc-mingw32/include" ignoring nonexistent directory "/usr/local/mingw32/include" #include "..." search starts here: #include <...> search starts here: C:/Temp/gcc/gcc-3.3-hiss/lib/gcc-lib/i686-pc-mingw32/3.3/include End of search list. 3.3.1 living in C:\Temp\gcc\gcc-3.3.1-purr says: ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3.1" ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3.1/i686-pc- mingw32" ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.3.1/backward" ignoring nonexistent directory "c:/temp/gcc/dest/include" ignoring nonexistent directory "/c/temp/gcc/dest/include" ignoring nonexistent directory "c:/temp/gcc/dest/lib/gcc-lib/i686-pc- mingw32/3.3.1/include" ignoring nonexistent directory "c:/temp/gcc/dest/i686-pc-mingw32/include" #include "..." search starts here: #include <...> search starts here: C:/Temp/gcc/gcc-3.3.1-purr/lib/gcc-lib/i686-pc-mingw32/3.3.1/include /mingw/include End of search list. 3.4.0 living in C:\Temp\gcc\gcc-3.4.0-oink says: ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.4.0" ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.4.0/i686-pc- mingw32" ignoring nonexistent directory "c:/temp/gcc/dest/include/c++/3.4.0/backward" ignoring nonexistent directory "c:/temp/gcc/dest/include" ignoring nonexistent directory "/c/temp/gcc/dest/include" ignoring nonexistent directory "c:/temp/gcc/dest/lib/gcc/i686-pc- mingw32/3.4.0/include" ignoring nonexistent directory "c:/temp/gcc/dest/i686-pc-mingw32/include" #include "..." search starts here: #include <...> search starts here: C:\Temp\gcc\gcc-3.4-oink\bin\../lib/gcc/i686-pc-mingw32/3.4.0/include /mingw/include End of search list. Interestingly, compiling hello.c using stdio.h with gcc 3.3.3 worked. I don't know why. Is this a problem with gcc? Am I not configuring my bootstraps properly? Since I can cross a compiler over and then move it to any old directory (i.e. C:\MinGW) I like, I figure that I should be able to bootstrap with a destination of C:\Temp\gcc\dest and then move it to any old directory. This is how I configured 3.3 during the cross: Reading specs from C:/MinGW/bin/../lib/gcc-lib/mingw32/3.3/specs Configured with: /home/stl/temp/src/configure --prefix=/home/stl/temp/dest -- build=i686-pc-linux-gnu --host=mingw32 --ta rget=mingw32 --enable-languages=c,c++ --with-gcc --with-gnu-as --with-gnu-ld -- with-as=/home/stl/xmingw32/bin/mingw32-as --with-ld=/home/stl/xmingw32/bin/mingw32-ld --enable-threads=win32 --disable- nls --disable-win32-registry --disable-sha red --enable-sjlj-exceptions --disable-debug --without-newlib Thread model: win32 gcc version 3.3 (mingw special 20030514-1) This is how I configured the 3.3.3 bootstrap: Using built-in specs. Configured with: ../src/configure --prefix=/c/temp/gcc/dest --enable- languages=c,c++ --enable-sjlj-exceptions --enable-t hreads=win32 --disable-win32-registry --disable-shared --without-newlib -- disable-nls --disable-debug Thread model: win32 gcc version 3.3.3 (mingw special)
After much frustrating work, I have crossed 3.3.3 and I can verify that it is directory-independent: it doesn't care what directory it is put in, it can always find its include files. The bootstrapped 3.3.3 is tied to the directory it was configured to be installed it. This is undesirable behavior: why should a native-native compiler be LESS useful than a crossed-native?
Changing summary to reflect my new understanding of the bug. I guess that this is not MinGW-specific, but people on GNU/Linux systems have no interest in moving their compiler around (since it's usually dumped in with a bunch of other programs). On Windows, the compiler is usually put into its own directory (e.g. C:\MinGW), except that not everyone agrees where that directory should be.
I routinely bootstrap gcc with native (msvcrt.dll-dependant) gcc.exe using cygwin's bash as shell and cygwin1.dll dependent tools. and have not seen this bug. The binaries built this way and distributed at mingw.org can be relocated into different directories, different drives and still find correct system includes and libs as long as PATH environment variable contains the gcc driver directory and the builtin relative GCC_EXEC_PREFIX hasn't been overriden by an env setting Danny
> I routinely bootstrap gcc with native (msvcrt.dll-dependant) gcc.exe using > cygwin's bash as shell and cygwin1.dll dependent tools. and have not seen > this bug. Okay - then this must be related to bootstrapping gcc in MSYS.
(In reply to comment #4) > > I routinely bootstrap gcc with native (msvcrt.dll-dependant) gcc.exe using > > cygwin's bash as shell and cygwin1.dll dependent tools. and have not seen > > this bug. > Okay - then this must be related to bootstrapping gcc in MSYS. I believe this one has been fixed with MSYS 1.10.0 on earlier versions if you configure with a full drive/pathname it works correctly i.e. --prefix=c:/crosstools
MSYS 1.0.10 (not a Release Candidate) and --prefix=/c/temp/gcc/dest does not fix the problem. I will try --prefix=c:/temp/gcc/dest next.
I can confirm that --prefix=c:/temp/gcc/dest produces a directory-independent bootstrapped compiler! I don't know whether this bug should be left open or not; it might be a gcc bug, or it might be an MSYS bug. It's fine with me if the bug is closed because a simple workaround exists. Probably this should be documented somewhere though.
Closing as this was a bug in the runtime and not in GCC.