| Message ID | 20211026124437.3301773-1-richard.purdie@linuxfoundation.org |
|---|---|
| State | New |
| Headers | show |
| Series | [1/4] Makefile.in: Ensure build CPP is used for build targets | expand |
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? > 2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org> > > Changelog: > > * Makefile.in: Use CC_FOR_BUILD as CPP for build targets > to avoid host/target contamination > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > --- > Makefile.in | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Makefile.in b/Makefile.in > index 34b2d89660d..f4815d7e75f 100644 > --- a/Makefile.in > +++ b/Makefile.in > @@ -152,6 +152,7 @@ BUILD_EXPORTS = \ > 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; \ > -- > 2.32.0 >
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
On Tue, Oct 26, 2021 at 2:57 PM Richard Purdie <richard.purdie@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 >
diff --git a/Makefile.in b/Makefile.in index 34b2d89660d..f4815d7e75f 100644 --- a/Makefile.in +++ b/Makefile.in @@ -152,6 +152,7 @@ BUILD_EXPORTS = \ 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; \
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. 2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org> Changelog: * Makefile.in: Use CC_FOR_BUILD as CPP for build targets to avoid host/target contamination Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- Makefile.in | 1 + 1 file changed, 1 insertion(+)