The OE environment sets and exports CPP as being the target gcc. When building gcc-cross-canadian for a mingw targetted sdk, the following can be found in build.x86_64-pokysdk-mingw32.i586-poky-linux/build-x86_64-linux/libiberty/config.log: configure:3641: checking for _FILE_OFFSET_BITS value needed for large files configure:3666: gcc -c -isystem/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe conftest.c >&5 configure:3666: $? = 0 configure:3698: result: no configure:3786: checking how to run the C preprocessor configure:3856: result: x86_64-pokysdk-mingw32-gcc -E --sysroot=/media/build1/poky/build/tmp/sysroots/x86_64-nativesdk-mingw32-pokysdk-mingw32 configure:3876: x86_64-pokysdk-mingw32-gcc -E --sysroot=/media/build1/poky/build/tmp/sysroots/x86_64-nativesdk-mingw32-pokysdk-mingw32 conftest.c configure:3876: $? = 0 Note this is a *build* target (in build-x86_64-linux) so it should be using the host "gcc", not x86_64-pokysdk-mingw32-gcc. Since the mingw32 headers are very different, using the wrong cpp is a real problem. It is leaking into configure through the CPP variable. Ultimately this leads to build failures related to not being able to include a process.h file for pem-unix.c. The fix is to ensure we export a sane CPP value into the build environment when using build targets. We could define a CPP_FOR_BUILD value which may be the version which needs to be upstreamed but for now, this fix is good enough to avoid the problem. RP 22/08/2013 Upstream-Status: Pending Index: gcc-4.8.1/Makefile.in =================================================================== --- gcc-4.8.1.orig/Makefile.in 2013-03-30 11:25:03.000000000 +0000 +++ gcc-4.8.1/Makefile.in 2013-08-13 12:03:17.151988882 +0000 @@ -149,6 +149,7 @@ AR="$(AR_FOR_BUILD)"; export AR; \ AS="$(AS_FOR_BUILD)"; export AS; \ CC="$(CC_FOR_BUILD)"; export CC; \ + CPP="$(CC_FOR_BUILD) -E"; export CPP; \ CFLAGS="$(CFLAGS_FOR_BUILD)"; export CFLAGS; \ CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \ CXX="$(CXX_FOR_BUILD)"; export CXX; \