On Tue, Oct 26, 2021 at 2:57 PM Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > > On Tue, 2021-10-26 at 14:55 +0200, Richard Biener wrote: > > On Tue, Oct 26, 2021 at 2:45 PM Richard Purdie via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > > > > > > During cross compiling, CPP is being set to the target compiler even for > > > build targets. As an example, when building a cross compiler targetting > > > mingw, the config.log for libiberty in > > > build.x86_64-pokysdk-mingw32.i586-poky-linux/build-x86_64-linux/libiberty/config.log > > > shows: > > > > > > configure:3786: checking how to run the C preprocessor > > > configure:3856: result: x86_64-pokysdk-mingw32-gcc -E > > > --sysroot=[sysroot]/x86_64-nativesdk-mingw32-pokysdk-mingw32 > > > configure:3876: x86_64-pokysdk-mingw32-gcc -E > > > --sysroot=[sysroot]/x86_64-nativesdk-mingw32-pokysdk-mingw32 conftest.c > > > configure:3876: $? = 0 > > > > > > This is libiberty being built for the build environment, not the target > > > one > > > (i.e. in build-x86_64-linux). As such it should be using the build > > > environment's > > > gcc and not the target one. In the mingw case the system headers are quite > > > different leading to build failures related to not being able to include a > > > process.h file for pem-unix.c. > > > > > > Fix this by using CC_FOR_BUILD instead of CC. Ultimately a CPP_FOR_BUILD > > > could be defined but CC_FOR_BUILD seems at least more correct and is a > > > simpler > > > fix. > > > > Since we're using AC_PROG_CPP to find the preprocessor simply assuming > > that $(CC_FOR_BUILD) -E works looks dangerous? > > Potentially, yes. So the route of adding CPP_FOR_BUILD would be preferred?
I would say so, yes. Richard. > > Cheers, > > Richard >
