Well it got to the next stage after I did this: >ln -s /mingw64/x86_64-w64-mingw32/include /home/jw/build-gcc-mingw64/x86_64-w64-mingw32/include But now it's stuck on an undefined reference: >C:\Users\JW\AppData\Local\Temp\ccrMv82H.ltrans0.ltrans.o:<artificial>:(.text+0x7428): undefined reference to `stpcpy' >collect2.exe: error: ld returned 1 exit status >make[4]: *** [Makefile:377: liblto_plugin.la] Error 1 >make[4]: Leaving directory '/home/JW/build-gcc-mingw64/lto-plugin' >make[3]: *** [Makefile:291: all] Error 2 >make[3]: Leaving directory '/home/JW/build-gcc-mingw64/lto-plugin' >make[2]: *** [Makefile:16108: all-stage2-lto-plugin] Error 2 >make[2]: Leaving directory '/home/JW/build-gcc-mingw64' >make[1]: *** [Makefile:23982: stage2-bubble] Error 2 >make[1]: Leaving directory '/home/JW/build-gcc-mingw64' >make: *** [Makefile:945: all] Error 2 Not sure what to do at this point. Shouldn't stpcpy be a part of the mingw64 runtime library? On 4 May 2017 at 16:42, J.W. Jagersma <jwjagersma@xxxxxxxxx> wrote: >>The former is used to build a native compiler. The latter isn't. > I know, but I got a long list of "unable to load dll" messages when > compiling with x86_64-w64-mingw32. That doesn't happen when > cross-compiling from x86_64-pc-msys. Those messages seem relatively > harmless though? It doesn't say what dll is missing or if it breaks > anything, but make doesn't count those as errors. > >>This looks relative to PR 70936. > Possibly? Not sure. This is the include path for the temporary xg++ > when invoked with the same command line as in the configure script: > >>$ echo | /home/JW/build-gcc-mingw64/./prev-gcc/xg++ -B/home/JW/build-gcc-mingw64/./prev-gcc/ -B/mingw64/x86_64-w64-mingw32/bin/ -nostdinc++ -B/home/JW/build-gcc-mingw64/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs -B/home/JW/build-gcc-mingw64/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -I/home/JW/build-gcc-mingw64/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I/home/JW/build-gcc-mingw64/prev-x86_64-w64-mingw32/libstdc++-v3/include -I/home/JW/gcc-7.1.0/libstdc++-v3/libsupc++ -L/home/JW/build-gcc-mingw64/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/home/JW/build-gcc-mingw64/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -E -Wp,-v - >>cc1.exe: warning: command line option '-nostdinc++' is valid for C++/ObjC++ but not for C >># 1 "<stdin>" >># 1 "<built-in>" >># 1 "<command-line>" >># 1 "<stdin>" >>ignoring nonexistent directory "d:\msys64\home\jw\build-gcc-mingw64\prev-gcc\../lib/gcc/x86_64-w64-mingw32/7.1.0/include" >>ignoring nonexistent directory "d:\msys64\home\jw\build-gcc-mingw64\prev-gcc\../lib/gcc/x86_64-w64-mingw32/7.1.0/../../../../include" >>ignoring nonexistent directory "d:\msys64\home\jw\build-gcc-mingw64\prev-gcc\../lib/gcc/x86_64-w64-mingw32/7.1.0/include-fixed" >>ignoring nonexistent directory "d:\msys64\home\jw\build-gcc-mingw64\prev-gcc\../lib/gcc/x86_64-w64-mingw32/7.1.0/../../../../x86_64-w64-mingw32/include" >>ignoring nonexistent directory "d:/msys64/home/jw/build-gcc-mingw64/lib/gcc/x86_64-w64-mingw32/7.1.0/include" >>ignoring nonexistent directory "/mingw64/include" >>ignoring nonexistent directory "d:/msys64/home/jw/build-gcc-mingw64/lib/gcc/x86_64-w64-mingw32/7.1.0/include-fixed" >>ignoring nonexistent directory "d:/msys64/home/jw/build-gcc-mingw64/x86_64-w64-mingw32/include" >>ignoring nonexistent directory "/mingw/include" >>#include "..." search starts here: >>#include <...> search starts here: >> D:/msys64/home/JW/build-gcc-mingw64/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 >> D:/msys64/home/JW/build-gcc-mingw64/prev-x86_64-w64-mingw32/libstdc++-v3/include >> D:/msys64/home/JW/gcc-7.1.0/libstdc++-v3/libsupc++ >> D:/msys64/home/JW/build-gcc-mingw64/prev-gcc/include >> D:/msys64/home/JW/build-gcc-mingw64/prev-gcc/include-fixed >> D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/7.1.0/../../../../include >>End of search list. > > I called configure with > "--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include", > so that's where it should be searching. But that doesn't appear > anywhere in the search list. I suppose I could copy/link the system > headers to one of the non-existent directories. Let's hope that > doesn't break anything else...
