[PATCH 1/4] Makefile.in: Ensure build CPP is used for build targets

Richard Purdie richard.purdie@linuxfoundation.org
Tue Oct 26 12:57:35 GMT 2021


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?

Cheers,

Richard



More information about the Gcc-patches mailing list