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

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

[Richard Purdie]

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(+)

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

[PATCH 2/4] gcc: Fix "argument list too long" from install-plugins

[Richard Purdie]

When building in longer build paths (200+ characters), the
"echo $(PLUGIN_HEADERS)" from the install-plugins target would cause an
"argument list too long error" on some systems.

Avoid this by calling make's sort function on the list which removes
duplicates and stops the overflow from reaching the echo command.
The original sort is left to handle the the .h and .def files.

2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>

gcc/ChangeLog:

    * Makefile.in: Fix "argument list too long" from install-plugins

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 gcc/Makefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 658093c11c0..89482c6dd4e 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3685,7 +3685,7 @@ install-plugin: installdirs lang.install-plugin s-header-vars install-gengtype
 # We keep the directory structure for files in config, common/config or
 # c-family and .def files. All other files are flattened to a single directory.
 	$(mkinstalldirs) $(DESTDIR)$(plugin_includedir)
-	headers=`echo $(PLUGIN_HEADERS) $$(cd $(srcdir); echo *.h *.def) | tr ' ' '\012' | sort -u`; \
+	headers=`echo $(sort $(PLUGIN_HEADERS)) $$(cd $(srcdir); echo *.h *.def) | tr ' ' '\012' | sort -u`; \
 	srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`; \
 	for file in $$headers; do \
 	  if [ -f $$file ] ; then \
-- 
2.32.0

[PATCH 3/4] gcc: Add --nostdlib++ option

[Richard Purdie]

OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
separately from the compiler and slightly differently to the standard gcc build.

In general this works well but in trying to build them separately we run into
an issue since we're using our gcc, not xgcc and there is no way to tell configure
to use libgcc but not look for libstdc++.

This adds such an option allowing such configurations to work.

2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>

gcc/c-family/ChangeLog:

    * c.opt: Add --nostdlib++ option

gcc/cp/ChangeLog:

    * g++spec.c (lang_specific_driver): Add --nostdlib++ option

gcc/ChangeLog:

    * doc/invoke.texi: Document --nostdlib++ option
    * gcc.c: Add --nostdlib++ option

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 gcc/c-family/c.opt  | 4 ++++
 gcc/cp/g++spec.c    | 1 +
 gcc/doc/invoke.texi | 8 ++++++--
 gcc/gcc.c           | 1 +
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 06457ac739e..ee742c831fd 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -2190,6 +2190,10 @@ nostdinc++
 C++ ObjC++
 Do not search standard system include directories for C++.
 
+nostdlib++
+Driver
+Do not link standard C++ runtime library
+
 o
 C ObjC C++ ObjC++ Joined Separate
 ; Documented in common.opt
diff --git a/gcc/cp/g++spec.c b/gcc/cp/g++spec.c
index 3c9bd1490b4..818beb61cee 100644
--- a/gcc/cp/g++spec.c
+++ b/gcc/cp/g++spec.c
@@ -159,6 +159,7 @@ lang_specific_driver (struct cl_decoded_option **in_decoded_options,
       switch (decoded_options[i].opt_index)
 	{
 	case OPT_nostdlib:
+	case OPT_nostdlib__:
 	case OPT_nodefaultlibs:
 	  library = -1;
 	  break;
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 71992b8c597..b30b79ebdc0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -236,7 +236,7 @@ in the following sections.
 -ftemplate-backtrace-limit=@var{n} @gol
 -ftemplate-depth=@var{n} @gol
 -fno-threadsafe-statics  -fuse-cxa-atexit @gol
--fno-weak  -nostdinc++ @gol
+-fno-weak  -nostdinc++  -nostdlib++ @gol
 -fvisibility-inlines-hidden @gol
 -fvisibility-ms-compat @gol
 -fext-numeric-literals @gol
@@ -633,7 +633,7 @@ Objective-C and Objective-C++ Dialects}.
 @item Linker Options
 @xref{Link Options,,Options for Linking}.
 @gccoptlist{@var{object-file-name}  -fuse-ld=@var{linker}  -l@var{library} @gol
--nostartfiles  -nodefaultlibs  -nolibc  -nostdlib @gol
+-nostartfiles  -nodefaultlibs  -nolibc  -nostdlib  -nostdlib++ @gol
 -e @var{entry}  --entry=@var{entry} @gol
 -pie  -pthread  -r  -rdynamic @gol
 -s  -static  -static-pie  -static-libgcc  -static-libstdc++ @gol
@@ -16125,6 +16125,10 @@ library subroutines.
 constructors are called; @pxref{Collect2,,@code{collect2}, gccint,
 GNU Compiler Collection (GCC) Internals}.)
 
+@item -nostdlib++
+@opindex nostdlib++
+Do not use the standard system C++ runtime libraries when linking.
+
 @item -e @var{entry}
 @itemx --entry=@var{entry}
 @opindex e
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 506c2acc282..abb900a4247 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1167,6 +1167,7 @@ proper position among the other output files.  */
     %(mflib) " STACK_SPLIT_SPEC "\
     %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " SANITIZER_SPEC " \
     %{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}}\
+    %{!nostdlib++:}\
     %{!nostdlib:%{!r:%{!nostartfiles:%E}}} %{T*}  \n%(post_link) }}}}}}"
 #endif
 
-- 
2.32.0

[PATCH 4/4] gcc/nios2: Define the musl linker

[Richard Purdie]

Add a definition of the musl linker used on the nios2 platform.

2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>

gcc/ChangeLog:

    * config/nios2/linux.h (MUSL_DYNAMIC_LINKER): Add musl linker

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 gcc/config/nios2/linux.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/nios2/linux.h b/gcc/config/nios2/linux.h
index 08edf1521f6..15696d86241 100644
--- a/gcc/config/nios2/linux.h
+++ b/gcc/config/nios2/linux.h
@@ -30,6 +30,7 @@
 #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
 
 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-nios2.so.1"
+#define MUSL_DYNAMIC_LINKER  "/lib/ld-musl-nios2.so.1"
 
 #undef LINK_SPEC
 #define LINK_SPEC LINK_SPEC_ENDIAN \
-- 
2.32.0

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

[Richard Biener]

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
>

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

[Richard Purdie]

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

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

[Richard Biener]

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
>