native x86_64-w64-mingw32 bootstrap using --with-sysroot This used to work for the 4.6 series. ../../src/gcc-4.7.0/configure --prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0 --with-gnu-as --with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/bin/as --with-gnu-ld --with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/bin/ld --build=x86_64-w64-mingw32 --enable-languages=c,ada,c++,fortran,java,lto,objc,obj-c++ --with-gmp-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-gmp-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-mpfr-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-mpfr-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-mpc-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-mpc-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-ppl-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-ppl-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-cloog-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-cloog-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0 --enable-libgomp --enable-fully-dynamic-string --disable-multilib --enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk --with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic' gcc 4.7.0 bootstrap fails during configuration in libgcc: checking how to run the C preprocessor... /lib/cpp configure: error: in `/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/x86_64-w64-mingw32/libgcc': configure: error: C preprocessor "/lib/cpp" fails sanity check See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0' gmake: *** [all] Error 2 config.log in libgcc shows: configure:3893: checking how to run the C preprocessor configure:3924: /SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/./gcc/xgcc -B/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/./gcc/ -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/lib -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/mingw/lib -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/mingw/include -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/bin/ -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/lib/ -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/sys-include -E conftest.c In file included from D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/syslimits.h:7:0, from D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/limits.h:34, from conftest.c:10: D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/limits.h:169:61: error: no include path in which to search for limits.h configure:3924: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" | /* end confdefs.h. */ | #ifdef __STDC__ | # include <limits.h> | #else | # include <assert.h> | #endif | Syntax error further analysis shows that the include search path composition is wrong. For gcc-4.6.3 stage1 xgcc the search path is as follows: nicht vorhandenes Verzeichnis »d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/x86_64-w64-mingw32/include« wird ignoriert nicht vorhandenes Verzeichnis »d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/mingw/include« wird ignoriert nicht vorhandenes Verzeichnis »d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/x86_64-w64-mingw32/include« wird ignoriert nicht vorhandenes Verzeichnis »d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/x86_64-w64-mingw32/sys-include« wird ignoriert nicht vorhandenes Verzeichnis »d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.6.3\gcc-4.6.3\gcc\../lib/gcc/x86_64-w64-mingw32/4.6.3/include« wird ignoriert nicht vorhandenes Verzeichnis »d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.6.3\gcc-4.6.3\gcc\../lib/gcc/x86_64-w64-mingw32/4.6.3/include-fixed« wird ignoriert nicht vorhandenes Verzeichnis »d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.6.3\gcc-4.6.3\gcc\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include« wird ignoriert nicht vorhandenes Verzeichnis »d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.6.3/gcc-4.6.3/lib/gcc/x86_64-w64-mingw32/4.6.3/include« wird ignoriert nicht vorhandenes Verzeichnis »D:/x86_64-w64-trunkd:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../include« wird ignoriert nicht vorhandenes Verzeichnis »d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.6.3/gcc-4.6.3/lib/gcc/x86_64-w64-mingw32/4.6.3/include-fixed« wird ignoriert nicht vorhandenes Verzeichnis »d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.6.3/gcc-4.6.3/x86_64-w64-mingw32/include« wird ignoriert #include "..." - Suche beginnt hier: #include <...> - Suche beginnt hier: D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.6.3/gcc-4.6.3/gcc/include D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.6.3/gcc-4.6.3/gcc/include-fixed D:/x86_64-w64-trunk/mingw/include Ende der Suchliste. As you see here the important search path component D:/x86_64-w64-trunk/mingw/include is ok. For gcc-4.7.0 in contrast I get: ignoring nonexistent directory "d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include" ignoring nonexistent directory "d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/mingw/include" ignoring nonexistent directory "d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include" ignoring nonexistent directory "d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/sys-include" ignoring nonexistent directory "d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.7.0\gcc-4.7.0\gcc\../lib/gcc/x86_64-w64-mingw32/4.7.0/include" ignoring nonexistent directory "d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.7.0\gcc-4.7.0\gcc\../lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed" ignoring nonexistent directory "d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.7.0\gcc-4.7.0\gcc\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.7.0/gcc-4.7.0/lib/gcc/x86_64-w64-mingw32/4.7.0/include" ignoring nonexistent directory "D:/x86_64-w64-trunkd:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include" ignoring nonexistent directory "d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.7.0/gcc-4.7.0/lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed" ignoring nonexistent directory "d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.7.0/gcc-4.7.0/x86_64-w64-mingw32/include" ignoring nonexistent directory "D:/x86_64-w64-trunkD:/msys/mingw/include" #include "..." search starts here: #include <...> search starts here: D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed Here the composition for the include search path gets wrong: ignoring nonexistent directory "D:/x86_64-w64-trunkD:/msys/mingw/include" The component /mingw/include is converted to an absolut windows path before it's appended to the sysroot. That's palin wrong. The library search path is ok. Any idea how to solve this?
I remember Kai did surgery in this place. Did you identify a patch that caused this regression? My bet would be 2011-03-25 Kai Tietz <ktietz@redhat.com> * collect2.c (write_c_file_stat): Handle backslash as right-hand directory separator. (resolve_lib_name): Use IS_DIR_SEPARATOR instead of checking just for slash. * coverage.c (coverage_init): Use IS_ABSOLUTE_PATH instead of checking for trailing slash. * gcc.c (record_temp_file): Use filename_cmp instead of strcmp. (do_spec_1): Likewise. ...
(In reply to comment #1) > I remember Kai did surgery in this place. Did you identify a patch that caused > this regression? My bet would be > > 2011-03-25 Kai Tietz <ktietz@redhat.com> > > * collect2.c (write_c_file_stat): Handle backslash > as right-hand directory separator. > (resolve_lib_name): Use IS_DIR_SEPARATOR instead of > checking just for slash. > * coverage.c (coverage_init): Use IS_ABSOLUTE_PATH > instead of checking for trailing slash. > * gcc.c (record_temp_file): Use filename_cmp instead > of strcmp. > (do_spec_1): Likewise. > ... To be honest, I don't know. I tried native bootstrapping on x86_64-w64-mingw32 at the beginning of last year but gave up due to the issues found. Lately I managed to bootstrap the 4.6 series with some manual intervention even ada included. There are still issues, one of them is really fundamental, but that's a different story. Btw. the PATH composition for --with-local-prefix is messed up the same way.
Just chiming in. Im also running into this problem in stage2 where it fails to find stdarg.h. As an experiment i tried reverting kai's work but it still fails to find system headers. A non bootstrap build works but im having problems with programs using libstdc++. All programs compiled that depends on libstdc++ will crash with initialization error 0xc000005. My machine is Win7 64. All previous gcc versions build fine btw. And work also. I have tried with versions compiled by other parts and the problem persists.
Adding --disable-build-poststage1-with-cxx \ --disable-build-with-cxx \ allows the full bootstrap on windows with mingw64. Something is broken with C++ though as anything that links to libstdc++ will crash with the executable has stopped working error (exceptions ?). I hope my findings can shed some light on this.
GCC 4.7.1 is being released, adjusting target milestone.
So, issue tracked down. It isn't related to the change I did for 4.7 version. At least not in a direct way. My changed fixed some issues, which now shown a hidden issue about msys' make, which changes happily arguments containing a POSIX-path to absolute DOS-style paths. By this NATIVE_SYSTEM_HEADER_DIR (which is /mingw/include) to something like 'D:/msys/mingw/include'. As native system-header-directory gets additionally prefixed by the specified sysroot, this leads to merging of two absolute DOS-style paths. So solution for this might be to redefine NATIVE_SYSTEM_HEADER_DIR within target's mingw32.h header for cases that TARGET_SYSTEM_ROOT is defined back to '/mingw/include'.
Author: ktietz Date: Fri Jul 6 18:54:20 2012 New Revision: 189338 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189338 Log: PR bootstrap/52947 * config/i386/mingw32.h (NATIVE_SYSTEM_HEADER_DIR): Define it always as "/mingw/include". Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mingw32.h
Author: ktietz Date: Fri Jul 6 18:56:09 2012 New Revision: 189339 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189339 Log: Backport from mainline. PR bootstrap/52947 * config/i386/mingw32.h (NATIVE_SYSTEM_HEADER_DIR): Define it always as "/mingw/include". Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/mingw32.h
Fixed.
New bug 56279 was introduced with this fix.