Hi,
I noticed a problem with the MingW package (mingw-4.2.0-070518.7z) provided by inkscape.modevia.com. The MingW with gcc 4.1.2 (zip package) didn't have this problem.
=================================================================== F:\mingw\bin>echo "#include <stdio.h>"|gcc -v -E - -o nul Using built-in specs. Target: i686-pc-mingw32 Configured with: ../configure --target=i686-pc-mingw32 --prefix=/mingw --enable- sjlj-exceptions --enable-threads=win32 --disable-win32-registry --enable-win32-r elocatable --enable-languages=c,c++ Thread model: win32 gcc version 4.2.0 f:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/cc1.exe -E -quiet -v -iprefix f:\mingw\bin../lib/gcc/i686-pc-mingw32/4.2.0/ - -o nul.exe -mtune=generic ignoring nonexistent directory "c:/mingw/lib/gcc/i686-pc-mingw32/4.2.0/include" ignoring nonexistent directory "c:/mingw/i686-pc-mingw32/include" #include "..." search starts here: #include <...> search starts here: f:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include c:/mingw/include /mingw/include /mingw/include End of search list.
F:\mingw\bin> ===================================================================
As you can see, gcc searches for C:\mingw\includes for headers even if executed on F:\mingw. This also happens if gcc is executed from places other than C:\mingw. This may introduce serious inconsistencies for Windows SVN testers with previously installed MinGW while debugging new builds.
Before the bashing begins, I already RTFM and written an ugly patch for it which involves passing -nostdinc -nostdinc++ to workaround drive space limitations on my machine. It would probably break automated builds, so I would avoid posting the patch here unless requested.
Any advice for better workarounds?