public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH 0/5] OpenEmbedded/Yocto Project gcc patches
@ 2021-10-27 20:05 Richard Purdie
  2021-10-27 20:05 ` [PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets Richard Purdie
                   ` (4 more replies)
  0 siblings, 5 replies; 20+ messages in thread
From: Richard Purdie @ 2021-10-27 20:05 UTC (permalink / raw)
  To: gcc-patches

OpenEmbedded/Yocto Project extensively uses gcc to cross compile in many
different and interesting places. On the most part we're very happy,
thanks! We do have a small collection of patches and I believe it would
be beneficial to share some of them.

I've picked some of the simpler ones and have tried to start that with
this series. I did send the first four once already but have reworked 
the first patch as advised (it became clear we had further related fixes 
too which I've merged in).

It may also be interesting for gcc developers to know that Yocto Project
is running the gcc test suite for each of the major architectures we target
under qemu (some in system, some in user mode) and collecting test results
with a view to trying to ensure we don't regress over time. As time
permits, we hope to track down failures and improve the pass rates too.

A report from our recent release is here:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4/testreport.txt

but is large so I placed some examples here:

=========================================================================
qemuppc PTest Result Summary
=========================================================================
-------------------------------------------------------------------------
Recipe                       | Passed       | Failed       | Skipped     
-------------------------------------------------------------------------
binutils                     | 221          | 2            | 13          
binutils-gas                 | 343          | 2            | 3           
binutils-ld                  | 1386         | 7            | 352         
gcc-g++-user                 | 195119       | 37           | 9389        
gcc-libatomic-user           | 44           | 0            | 5           
gcc-libgomp-user             | 2788         | 2            | 370         
gcc-libitm-user              | 46           | 0            | 2           
gcc-libstdc++-v3-user        | 14152        | 7            | 723         
gcc-user                     | 134355       | 200          | 4104        
glibc-user                   | 3869         | 210          | 76          
-------------------------------------------------------------------------

=========================================================================
qemux86 PTest Result Summary
=========================================================================
-------------------------------------------------------------------------
Recipe                       | Passed       | Failed       | Skipped     
-------------------------------------------------------------------------
binutils                     | 230          | 2            | 13          
binutils-gas                 | 1485         | 0            | 1           
binutils-ld                  | 1641         | 7            | 354         
gcc                          | 124619       | 132          | 26160       
gcc-g++                      | 186472       | 56           | 19103       
gcc-libatomic                | 22           | 1            | 27          
gcc-libgomp                  | 1427         | 2            | 1671        
gcc-libitm                   | 24           | 1            | 24          
gcc-libstdc++-v3             | 9102         | 33           | 5216        
glibc                        | 4230         | 203          | 40          

Cheers,

Richard

Richard Purdie (5):
  Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets
  gcc: Fix "argument list too long" from install-plugins
  gcc: Add --nostdlib++ option
  gcc/nios2: Define the musl linker
  gcc: Pass sysroot options to cpp for preprocessed source

 Makefile.in              | 6 ++++++
 Makefile.tpl             | 6 ++++++
 configure                | 4 ++++
 configure.ac             | 4 ++++
 gcc/Makefile.in          | 2 +-
 gcc/c-family/c.opt       | 4 ++++
 gcc/config/nios2/linux.h | 1 +
 gcc/configure            | 2 +-
 gcc/configure.ac         | 2 +-
 gcc/cp/g++spec.c         | 1 +
 gcc/cp/lang-specs.h      | 2 +-
 gcc/doc/invoke.texi      | 8 +++++++-
 gcc/gcc.c                | 3 ++-
 13 files changed, 39 insertions(+), 6 deletions(-)

-- 
2.25.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets
  2021-10-27 20:05 [PATCH 0/5] OpenEmbedded/Yocto Project gcc patches Richard Purdie
@ 2021-10-27 20:05 ` Richard Purdie
  2021-10-28  7:04   ` Richard Biener
  2021-10-27 20:05 ` [PATCH 2/5] gcc: Fix "argument list too long" from install-plugins Richard Purdie
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 20+ messages in thread
From: Richard Purdie @ 2021-10-27 20:05 UTC (permalink / raw)
  To: gcc-patches

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.

Further analysis shows the same issue occuring for CPPFLAGS too.

Fix this by adding support for CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD which
for example, avoids mixing the mingw headers for host binaries on linux
systems.

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

ChangeLog:

    * Makefile.tpl: Add CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD support
    * Makefile.in: Regenerate.
    * configure: Regenerate.
    * configure.ac: Add CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD support

gcc/ChangeLog:

    * configure: Regenerate.
    * configure.ac: Use CPPFLAGS_FOR_BUILD for GMPINC

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 Makefile.in      | 6 ++++++
 Makefile.tpl     | 6 ++++++
 configure        | 4 ++++
 configure.ac     | 4 ++++
 gcc/configure    | 2 +-
 gcc/configure.ac | 2 +-
 6 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 34b2d89660d..d13f6c353ee 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -154,6 +154,8 @@ BUILD_EXPORTS = \
 	CC="$(CC_FOR_BUILD)"; export CC; \
 	CFLAGS="$(CFLAGS_FOR_BUILD)"; export CFLAGS; \
 	CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \
+	CPP="$(CPP_FOR_BUILD)"; export CPP; \
+	CPPFLAGS="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS; \
 	CXX="$(CXX_FOR_BUILD)"; export CXX; \
 	CXXFLAGS="$(CXXFLAGS_FOR_BUILD)"; export CXXFLAGS; \
 	GFORTRAN="$(GFORTRAN_FOR_BUILD)"; export GFORTRAN; \
@@ -202,6 +204,8 @@ HOST_EXPORTS = \
 	AR="$(AR)"; export AR; \
 	AS="$(AS)"; export AS; \
 	CC_FOR_BUILD="$(CC_FOR_BUILD)"; export CC_FOR_BUILD; \
+	CPP_FOR_BUILD="$(CPP_FOR_BUILD)"; export CPP_FOR_BUILD; \
+	CPPFLAGS_FOR_BUILD="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS_FOR_BUILD; \
 	CXX_FOR_BUILD="$(CXX_FOR_BUILD)"; export CXX_FOR_BUILD; \
 	DLLTOOL="$(DLLTOOL)"; export DLLTOOL; \
 	DSYMUTIL="$(DSYMUTIL)"; export DSYMUTIL; \
@@ -360,6 +364,8 @@ AR_FOR_BUILD = @AR_FOR_BUILD@
 AS_FOR_BUILD = @AS_FOR_BUILD@
 CC_FOR_BUILD = @CC_FOR_BUILD@
 CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@
+CPP_FOR_BUILD = @CPP_FOR_BUILD@
+CPPFLAGS_FOR_BUILD = @CPPFLAGS_FOR_BUILD@
 CXXFLAGS_FOR_BUILD = @CXXFLAGS_FOR_BUILD@
 CXX_FOR_BUILD = @CXX_FOR_BUILD@
 DLLTOOL_FOR_BUILD = @DLLTOOL_FOR_BUILD@
diff --git a/Makefile.tpl b/Makefile.tpl
index 08e68e83ea8..213052f8226 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -157,6 +157,8 @@ BUILD_EXPORTS = \
 	CC="$(CC_FOR_BUILD)"; export CC; \
 	CFLAGS="$(CFLAGS_FOR_BUILD)"; export CFLAGS; \
 	CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \
+	CPP="$(CPP_FOR_BUILD)"; export CPP; \
+	CPPFLAGS="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS; \
 	CXX="$(CXX_FOR_BUILD)"; export CXX; \
 	CXXFLAGS="$(CXXFLAGS_FOR_BUILD)"; export CXXFLAGS; \
 	GFORTRAN="$(GFORTRAN_FOR_BUILD)"; export GFORTRAN; \
@@ -205,6 +207,8 @@ HOST_EXPORTS = \
 	AR="$(AR)"; export AR; \
 	AS="$(AS)"; export AS; \
 	CC_FOR_BUILD="$(CC_FOR_BUILD)"; export CC_FOR_BUILD; \
+	CPP_FOR_BUILD="$(CPP_FOR_BUILD)"; export CPP_FOR_BUILD; \
+	CPPFLAGS_FOR_BUILD="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS_FOR_BUILD; \
 	CXX_FOR_BUILD="$(CXX_FOR_BUILD)"; export CXX_FOR_BUILD; \
 	DLLTOOL="$(DLLTOOL)"; export DLLTOOL; \
 	DSYMUTIL="$(DSYMUTIL)"; export DSYMUTIL; \
@@ -363,6 +367,8 @@ AR_FOR_BUILD = @AR_FOR_BUILD@
 AS_FOR_BUILD = @AS_FOR_BUILD@
 CC_FOR_BUILD = @CC_FOR_BUILD@
 CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@
+CPP_FOR_BUILD = @CPP_FOR_BUILD@
+CPPFLAGS_FOR_BUILD = @CPPFLAGS_FOR_BUILD@
 CXXFLAGS_FOR_BUILD = @CXXFLAGS_FOR_BUILD@
 CXX_FOR_BUILD = @CXX_FOR_BUILD@
 DLLTOOL_FOR_BUILD = @DLLTOOL_FOR_BUILD@
diff --git a/configure b/configure
index 785498efff5..58979d6e3b1 100755
--- a/configure
+++ b/configure
@@ -655,6 +655,8 @@ DSYMUTIL_FOR_BUILD
 DLLTOOL_FOR_BUILD
 CXX_FOR_BUILD
 CXXFLAGS_FOR_BUILD
+CPPFLAGS_FOR_BUILD
+CPP_FOR_BUILD
 CFLAGS_FOR_BUILD
 CC_FOR_BUILD
 AS_FOR_BUILD
@@ -4090,6 +4092,7 @@ if test "${build}" != "${host}" ; then
   AR_FOR_BUILD=${AR_FOR_BUILD-ar}
   AS_FOR_BUILD=${AS_FOR_BUILD-as}
   CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
+  CPP_FOR_BUILD="${CPP_FOR_BUILD-\$(CPP)}"
   CXX_FOR_BUILD=${CXX_FOR_BUILD-g++}
   DSYMUTIL_FOR_BUILD=${DSYMUTIL_FOR_BUILD-dsymutil}
   GFORTRAN_FOR_BUILD=${GFORTRAN_FOR_BUILD-gfortran}
@@ -9999,6 +10002,7 @@ esac
 # our build compiler if desired.
 if test x"${build}" = x"${host}" ; then
   CFLAGS_FOR_BUILD=${CFLAGS_FOR_BUILD-${CFLAGS}}
+  CPPFLAGS_FOR_BUILD=${CPPFLAGS_FOR_BUILD-${CPPFLAGS}}
   CXXFLAGS_FOR_BUILD=${CXXFLAGS_FOR_BUILD-${CXXFLAGS}}
   LDFLAGS_FOR_BUILD=${LDFLAGS_FOR_BUILD-${LDFLAGS}}
 fi
diff --git a/configure.ac b/configure.ac
index c523083c346..550e6993b59 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1334,6 +1334,7 @@ if test "${build}" != "${host}" ; then
   AR_FOR_BUILD=${AR_FOR_BUILD-ar}
   AS_FOR_BUILD=${AS_FOR_BUILD-as}
   CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
+  CPP_FOR_BUILD="${CPP_FOR_BUILD-\$(CPP)}"
   CXX_FOR_BUILD=${CXX_FOR_BUILD-g++}
   DSYMUTIL_FOR_BUILD=${DSYMUTIL_FOR_BUILD-dsymutil}
   GFORTRAN_FOR_BUILD=${GFORTRAN_FOR_BUILD-gfortran}
@@ -3323,6 +3324,7 @@ esac
 # our build compiler if desired.
 if test x"${build}" = x"${host}" ; then
   CFLAGS_FOR_BUILD=${CFLAGS_FOR_BUILD-${CFLAGS}}
+  CPPFLAGS_FOR_BUILD=${CPPFLAGS_FOR_BUILD-${CPPFLAGS}}
   CXXFLAGS_FOR_BUILD=${CXXFLAGS_FOR_BUILD-${CXXFLAGS}}
   LDFLAGS_FOR_BUILD=${LDFLAGS_FOR_BUILD-${LDFLAGS}}
 fi
@@ -3389,6 +3391,8 @@ AC_SUBST(AR_FOR_BUILD)
 AC_SUBST(AS_FOR_BUILD)
 AC_SUBST(CC_FOR_BUILD)
 AC_SUBST(CFLAGS_FOR_BUILD)
+AC_SUBST(CPP_FOR_BUILD)
+AC_SUBST(CPPFLAGS_FOR_BUILD)
 AC_SUBST(CXXFLAGS_FOR_BUILD)
 AC_SUBST(CXX_FOR_BUILD)
 AC_SUBST(DLLTOOL_FOR_BUILD)
diff --git a/gcc/configure b/gcc/configure
index eeb42657da2..920868bcd33 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -12769,7 +12769,7 @@ else
 	CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
 	CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
 	LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
-	GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
+	GMPINC="" CPPFLAGS="${CPPFLAGS_FOR_BUILD} -DGENERATOR_FILE" \
 	${realsrcdir}/configure \
 		--enable-languages=${enable_languages-all} \
 		${enable_obsolete+--enable-obsolete="$enable_obsolete"} \
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 8c60c0f5e46..065080a4b39 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2065,7 +2065,7 @@ else
 	CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
 	CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
 	LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
-	GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
+	GMPINC="" CPPFLAGS="${CPPFLAGS_FOR_BUILD} -DGENERATOR_FILE" \
 	${realsrcdir}/configure \
 		--enable-languages=${enable_languages-all} \
 		${enable_obsolete+--enable-obsolete="$enable_obsolete"} \
-- 
2.25.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 2/5] gcc: Fix "argument list too long" from install-plugins
  2021-10-27 20:05 [PATCH 0/5] OpenEmbedded/Yocto Project gcc patches Richard Purdie
  2021-10-27 20:05 ` [PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets Richard Purdie
@ 2021-10-27 20:05 ` Richard Purdie
  2021-10-27 20:54   ` Bernhard Reutner-Fischer
  2021-12-03  3:01   ` Jeff Law
  2021-10-27 20:05 ` [PATCH 3/5] gcc: Add --nostdlib++ option Richard Purdie
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 20+ messages in thread
From: Richard Purdie @ 2021-10-27 20:05 UTC (permalink / raw)
  To: gcc-patches

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.25.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-10-27 20:05 [PATCH 0/5] OpenEmbedded/Yocto Project gcc patches Richard Purdie
  2021-10-27 20:05 ` [PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets Richard Purdie
  2021-10-27 20:05 ` [PATCH 2/5] gcc: Fix "argument list too long" from install-plugins Richard Purdie
@ 2021-10-27 20:05 ` Richard Purdie
  2021-10-27 20:56   ` Bernhard Reutner-Fischer
  2021-10-28 14:51   ` Jeff Law
  2021-10-27 20:05 ` [PATCH 4/5] gcc/nios2: Define the musl linker Richard Purdie
  2021-10-27 20:05 ` [PATCH 5/5] gcc: Pass sysroot options to cpp for preprocessed source Richard Purdie
  4 siblings, 2 replies; 20+ messages in thread
From: Richard Purdie @ 2021-10-27 20:05 UTC (permalink / raw)
  To: gcc-patches

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, 13 insertions(+), 1 deletion(-)

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..d89b08b3080 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -239,6 +239,7 @@ in the following sections.
 -fno-weak  -nostdinc++ @gol
 -fvisibility-inlines-hidden @gol
 -fvisibility-ms-compat @gol
+-nostdlib++ @gol
 -fext-numeric-literals @gol
 -flang-info-include-translate@r{[}=@var{header}@r{]} @gol
 -flang-info-include-translate-not @gol
@@ -638,7 +639,7 @@ Objective-C and Objective-C++ Dialects}.
 -pie  -pthread  -r  -rdynamic @gol
 -s  -static  -static-pie  -static-libgcc  -static-libstdc++ @gol
 -static-libasan  -static-libtsan  -static-liblsan  -static-libubsan @gol
--shared  -shared-libgcc  -symbolic @gol
+-shared  -shared-libgcc  -symbolic -nostdlib++ @gol
 -T @var{script}  -Wl,@var{option}  -Xlinker @var{option} @gol
 -u @var{symbol}  -z @var{keyword}}
 
@@ -16134,6 +16135,11 @@ Specify that the program entry point is @var{entry}.  The argument is
 interpreted by the linker; the GNU linker accepts either a symbol name
 or an address.
 
+@item -nostdlib++
+@opindex nostdlib++
+Do not use the standard system C++ runtime libraries when linking.
+Only the libraries you specify will be passed to the linker.
+
 @item -pie
 @opindex pie
 Produce a dynamically linked position independent executable on targets
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.25.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 4/5] gcc/nios2: Define the musl linker
  2021-10-27 20:05 [PATCH 0/5] OpenEmbedded/Yocto Project gcc patches Richard Purdie
                   ` (2 preceding siblings ...)
  2021-10-27 20:05 ` [PATCH 3/5] gcc: Add --nostdlib++ option Richard Purdie
@ 2021-10-27 20:05 ` Richard Purdie
  2021-10-28 14:46   ` Jeff Law
  2021-10-27 20:05 ` [PATCH 5/5] gcc: Pass sysroot options to cpp for preprocessed source Richard Purdie
  4 siblings, 1 reply; 20+ messages in thread
From: Richard Purdie @ 2021-10-27 20:05 UTC (permalink / raw)
  To: gcc-patches

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.25.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH 5/5] gcc: Pass sysroot options to cpp for preprocessed source
  2021-10-27 20:05 [PATCH 0/5] OpenEmbedded/Yocto Project gcc patches Richard Purdie
                   ` (3 preceding siblings ...)
  2021-10-27 20:05 ` [PATCH 4/5] gcc/nios2: Define the musl linker Richard Purdie
@ 2021-10-27 20:05 ` Richard Purdie
  2021-12-14 23:47   ` Jeff Law
  4 siblings, 1 reply; 20+ messages in thread
From: Richard Purdie @ 2021-10-27 20:05 UTC (permalink / raw)
  To: gcc-patches

OpenEmbedded/Yocto Project extensively uses the --sysroot support within gcc.
We discovered that when compiling preprocessed source (.i or .ii files), the
compiler will try and access the builtin sysroot location rather than the
--sysroot option specified on the commandline. If access to that directory is
permission denied (unreadable), gcc will error. This is particularly problematic
when ccache is involved.

This patch adds %I to the cpp-output spec macro so the default substitutions for
-iprefix, -isystem, -isysroot happen and the correct sysroot is used.

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

gcc/cp/ChangeLog:

    * lang-specs.h: Pass sysroot options to cpp for preprocessed source

gcc/ChangeLog:

    * gcc.c: Pass sysroot options to cpp for preprocessed source

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 gcc/cp/lang-specs.h | 2 +-
 gcc/gcc.c           | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/lang-specs.h b/gcc/cp/lang-specs.h
index 8902ae1d2ed..e99e2fcd6ad 100644
--- a/gcc/cp/lang-specs.h
+++ b/gcc/cp/lang-specs.h
@@ -116,7 +116,7 @@ along with GCC; see the file COPYING3.  If not see
   {".ii", "@c++-cpp-output", 0, 0, 0},
   {"@c++-cpp-output",
       "%{!E:%{!M:%{!MM:"
-      "  cc1plus -fpreprocessed %i %(cc1_options) %2"
+      "  cc1plus -fpreprocessed %i %I %(cc1_options) %2"
       "  %{!fsyntax-only:"
       "    %{fmodule-only:%{!S:-o %g.s%V}}"
       "    %{!fmodule-only:%{!fmodule-header*:%(invoke_as)}}}"
diff --git a/gcc/gcc.c b/gcc/gcc.c
index abb900a4247..51176becb86 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1472,7 +1472,7 @@ static const struct compiler default_compilers[] =
 					   %W{o*:--output-pch=%*}}%V}}}}}}}", 0, 0, 0},
   {".i", "@cpp-output", 0, 0, 0},
   {"@cpp-output",
-   "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options) %{!fsyntax-only:%(invoke_as)}}}}", 0, 0, 0},
+   "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %I %(cc1_options) %{!fsyntax-only:%(invoke_as)}}}}", 0, 0, 0},
   {".s", "@assembler", 0, 0, 0},
   {"@assembler",
    "%{!M:%{!MM:%{!E:%{!S:as %(asm_debug) %(asm_options) %i %A }}}}", 0, 0, 0},
-- 
2.25.1


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/5] gcc: Fix "argument list too long" from install-plugins
  2021-10-27 20:05 ` [PATCH 2/5] gcc: Fix "argument list too long" from install-plugins Richard Purdie
@ 2021-10-27 20:54   ` Bernhard Reutner-Fischer
  2021-12-03  3:01   ` Jeff Law
  1 sibling, 0 replies; 20+ messages in thread
From: Bernhard Reutner-Fischer @ 2021-10-27 20:54 UTC (permalink / raw)
  To: Richard Purdie via Gcc-patches

On Wed, 27 Oct 2021 21:05:02 +0100
Richard Purdie via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:

> 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.

you could as well $(subst $(srcdir),,$(wildcard $(addprefix
$(srcdir),*.h *.def))) and subst '' with '\012' wrapped in an outer
sort to completely do away with the echo and shell sort i suppose.
Just an idea.
thanks,
> 
> 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 \


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-10-27 20:05 ` [PATCH 3/5] gcc: Add --nostdlib++ option Richard Purdie
@ 2021-10-27 20:56   ` Bernhard Reutner-Fischer
  2021-10-28 16:41     ` Richard Purdie
  2021-10-28 14:51   ` Jeff Law
  1 sibling, 1 reply; 20+ messages in thread
From: Bernhard Reutner-Fischer @ 2021-10-27 20:56 UTC (permalink / raw)
  To: Richard Purdie via Gcc-patches

On Wed, 27 Oct 2021 21:05:03 +0100
Richard Purdie via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:

> 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.

But shouldn't it be called --nostdlibc++ then?
thanks,

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets
  2021-10-27 20:05 ` [PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets Richard Purdie
@ 2021-10-28  7:04   ` Richard Biener
  2021-10-28 14:43     ` Jeff Law
  0 siblings, 1 reply; 20+ messages in thread
From: Richard Biener @ 2021-10-28  7:04 UTC (permalink / raw)
  To: Richard Purdie; +Cc: GCC Patches

On Wed, Oct 27, 2021 at 10:10 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.
>
> Further analysis shows the same issue occuring for CPPFLAGS too.
>
> Fix this by adding support for CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD which
> for example, avoids mixing the mingw headers for host binaries on linux
> systems.

OK.

Thanks,
Richard.

> 2021-10-27 Richard Purdie <richard.purdie@linuxfoundation.org>
>
> ChangeLog:
>
>     * Makefile.tpl: Add CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD support
>     * Makefile.in: Regenerate.
>     * configure: Regenerate.
>     * configure.ac: Add CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD support
>
> gcc/ChangeLog:
>
>     * configure: Regenerate.
>     * configure.ac: Use CPPFLAGS_FOR_BUILD for GMPINC
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  Makefile.in      | 6 ++++++
>  Makefile.tpl     | 6 ++++++
>  configure        | 4 ++++
>  configure.ac     | 4 ++++
>  gcc/configure    | 2 +-
>  gcc/configure.ac | 2 +-
>  6 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile.in b/Makefile.in
> index 34b2d89660d..d13f6c353ee 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -154,6 +154,8 @@ BUILD_EXPORTS = \
>         CC="$(CC_FOR_BUILD)"; export CC; \
>         CFLAGS="$(CFLAGS_FOR_BUILD)"; export CFLAGS; \
>         CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \
> +       CPP="$(CPP_FOR_BUILD)"; export CPP; \
> +       CPPFLAGS="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS; \
>         CXX="$(CXX_FOR_BUILD)"; export CXX; \
>         CXXFLAGS="$(CXXFLAGS_FOR_BUILD)"; export CXXFLAGS; \
>         GFORTRAN="$(GFORTRAN_FOR_BUILD)"; export GFORTRAN; \
> @@ -202,6 +204,8 @@ HOST_EXPORTS = \
>         AR="$(AR)"; export AR; \
>         AS="$(AS)"; export AS; \
>         CC_FOR_BUILD="$(CC_FOR_BUILD)"; export CC_FOR_BUILD; \
> +       CPP_FOR_BUILD="$(CPP_FOR_BUILD)"; export CPP_FOR_BUILD; \
> +       CPPFLAGS_FOR_BUILD="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS_FOR_BUILD; \
>         CXX_FOR_BUILD="$(CXX_FOR_BUILD)"; export CXX_FOR_BUILD; \
>         DLLTOOL="$(DLLTOOL)"; export DLLTOOL; \
>         DSYMUTIL="$(DSYMUTIL)"; export DSYMUTIL; \
> @@ -360,6 +364,8 @@ AR_FOR_BUILD = @AR_FOR_BUILD@
>  AS_FOR_BUILD = @AS_FOR_BUILD@
>  CC_FOR_BUILD = @CC_FOR_BUILD@
>  CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@
> +CPP_FOR_BUILD = @CPP_FOR_BUILD@
> +CPPFLAGS_FOR_BUILD = @CPPFLAGS_FOR_BUILD@
>  CXXFLAGS_FOR_BUILD = @CXXFLAGS_FOR_BUILD@
>  CXX_FOR_BUILD = @CXX_FOR_BUILD@
>  DLLTOOL_FOR_BUILD = @DLLTOOL_FOR_BUILD@
> diff --git a/Makefile.tpl b/Makefile.tpl
> index 08e68e83ea8..213052f8226 100644
> --- a/Makefile.tpl
> +++ b/Makefile.tpl
> @@ -157,6 +157,8 @@ BUILD_EXPORTS = \
>         CC="$(CC_FOR_BUILD)"; export CC; \
>         CFLAGS="$(CFLAGS_FOR_BUILD)"; export CFLAGS; \
>         CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \
> +       CPP="$(CPP_FOR_BUILD)"; export CPP; \
> +       CPPFLAGS="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS; \
>         CXX="$(CXX_FOR_BUILD)"; export CXX; \
>         CXXFLAGS="$(CXXFLAGS_FOR_BUILD)"; export CXXFLAGS; \
>         GFORTRAN="$(GFORTRAN_FOR_BUILD)"; export GFORTRAN; \
> @@ -205,6 +207,8 @@ HOST_EXPORTS = \
>         AR="$(AR)"; export AR; \
>         AS="$(AS)"; export AS; \
>         CC_FOR_BUILD="$(CC_FOR_BUILD)"; export CC_FOR_BUILD; \
> +       CPP_FOR_BUILD="$(CPP_FOR_BUILD)"; export CPP_FOR_BUILD; \
> +       CPPFLAGS_FOR_BUILD="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS_FOR_BUILD; \
>         CXX_FOR_BUILD="$(CXX_FOR_BUILD)"; export CXX_FOR_BUILD; \
>         DLLTOOL="$(DLLTOOL)"; export DLLTOOL; \
>         DSYMUTIL="$(DSYMUTIL)"; export DSYMUTIL; \
> @@ -363,6 +367,8 @@ AR_FOR_BUILD = @AR_FOR_BUILD@
>  AS_FOR_BUILD = @AS_FOR_BUILD@
>  CC_FOR_BUILD = @CC_FOR_BUILD@
>  CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@
> +CPP_FOR_BUILD = @CPP_FOR_BUILD@
> +CPPFLAGS_FOR_BUILD = @CPPFLAGS_FOR_BUILD@
>  CXXFLAGS_FOR_BUILD = @CXXFLAGS_FOR_BUILD@
>  CXX_FOR_BUILD = @CXX_FOR_BUILD@
>  DLLTOOL_FOR_BUILD = @DLLTOOL_FOR_BUILD@
> diff --git a/configure b/configure
> index 785498efff5..58979d6e3b1 100755
> --- a/configure
> +++ b/configure
> @@ -655,6 +655,8 @@ DSYMUTIL_FOR_BUILD
>  DLLTOOL_FOR_BUILD
>  CXX_FOR_BUILD
>  CXXFLAGS_FOR_BUILD
> +CPPFLAGS_FOR_BUILD
> +CPP_FOR_BUILD
>  CFLAGS_FOR_BUILD
>  CC_FOR_BUILD
>  AS_FOR_BUILD
> @@ -4090,6 +4092,7 @@ if test "${build}" != "${host}" ; then
>    AR_FOR_BUILD=${AR_FOR_BUILD-ar}
>    AS_FOR_BUILD=${AS_FOR_BUILD-as}
>    CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
> +  CPP_FOR_BUILD="${CPP_FOR_BUILD-\$(CPP)}"
>    CXX_FOR_BUILD=${CXX_FOR_BUILD-g++}
>    DSYMUTIL_FOR_BUILD=${DSYMUTIL_FOR_BUILD-dsymutil}
>    GFORTRAN_FOR_BUILD=${GFORTRAN_FOR_BUILD-gfortran}
> @@ -9999,6 +10002,7 @@ esac
>  # our build compiler if desired.
>  if test x"${build}" = x"${host}" ; then
>    CFLAGS_FOR_BUILD=${CFLAGS_FOR_BUILD-${CFLAGS}}
> +  CPPFLAGS_FOR_BUILD=${CPPFLAGS_FOR_BUILD-${CPPFLAGS}}
>    CXXFLAGS_FOR_BUILD=${CXXFLAGS_FOR_BUILD-${CXXFLAGS}}
>    LDFLAGS_FOR_BUILD=${LDFLAGS_FOR_BUILD-${LDFLAGS}}
>  fi
> diff --git a/configure.ac b/configure.ac
> index c523083c346..550e6993b59 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1334,6 +1334,7 @@ if test "${build}" != "${host}" ; then
>    AR_FOR_BUILD=${AR_FOR_BUILD-ar}
>    AS_FOR_BUILD=${AS_FOR_BUILD-as}
>    CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
> +  CPP_FOR_BUILD="${CPP_FOR_BUILD-\$(CPP)}"
>    CXX_FOR_BUILD=${CXX_FOR_BUILD-g++}
>    DSYMUTIL_FOR_BUILD=${DSYMUTIL_FOR_BUILD-dsymutil}
>    GFORTRAN_FOR_BUILD=${GFORTRAN_FOR_BUILD-gfortran}
> @@ -3323,6 +3324,7 @@ esac
>  # our build compiler if desired.
>  if test x"${build}" = x"${host}" ; then
>    CFLAGS_FOR_BUILD=${CFLAGS_FOR_BUILD-${CFLAGS}}
> +  CPPFLAGS_FOR_BUILD=${CPPFLAGS_FOR_BUILD-${CPPFLAGS}}
>    CXXFLAGS_FOR_BUILD=${CXXFLAGS_FOR_BUILD-${CXXFLAGS}}
>    LDFLAGS_FOR_BUILD=${LDFLAGS_FOR_BUILD-${LDFLAGS}}
>  fi
> @@ -3389,6 +3391,8 @@ AC_SUBST(AR_FOR_BUILD)
>  AC_SUBST(AS_FOR_BUILD)
>  AC_SUBST(CC_FOR_BUILD)
>  AC_SUBST(CFLAGS_FOR_BUILD)
> +AC_SUBST(CPP_FOR_BUILD)
> +AC_SUBST(CPPFLAGS_FOR_BUILD)
>  AC_SUBST(CXXFLAGS_FOR_BUILD)
>  AC_SUBST(CXX_FOR_BUILD)
>  AC_SUBST(DLLTOOL_FOR_BUILD)
> diff --git a/gcc/configure b/gcc/configure
> index eeb42657da2..920868bcd33 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -12769,7 +12769,7 @@ else
>         CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
>         CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
>         LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
> -       GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
> +       GMPINC="" CPPFLAGS="${CPPFLAGS_FOR_BUILD} -DGENERATOR_FILE" \
>         ${realsrcdir}/configure \
>                 --enable-languages=${enable_languages-all} \
>                 ${enable_obsolete+--enable-obsolete="$enable_obsolete"} \
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 8c60c0f5e46..065080a4b39 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -2065,7 +2065,7 @@ else
>         CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
>         CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
>         LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
> -       GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
> +       GMPINC="" CPPFLAGS="${CPPFLAGS_FOR_BUILD} -DGENERATOR_FILE" \
>         ${realsrcdir}/configure \
>                 --enable-languages=${enable_languages-all} \
>                 ${enable_obsolete+--enable-obsolete="$enable_obsolete"} \
> --
> 2.25.1
>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets
  2021-10-28  7:04   ` Richard Biener
@ 2021-10-28 14:43     ` Jeff Law
  0 siblings, 0 replies; 20+ messages in thread
From: Jeff Law @ 2021-10-28 14:43 UTC (permalink / raw)
  To: Richard Biener, Richard Purdie; +Cc: GCC Patches



On 10/28/2021 1:04 AM, Richard Biener via Gcc-patches wrote:
> On Wed, Oct 27, 2021 at 10:10 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.
>>
>> Further analysis shows the same issue occuring for CPPFLAGS too.
>>
>> Fix this by adding support for CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD which
>> for example, avoids mixing the mingw headers for host binaries on linux
>> systems.
> OK.
I don't think Richard P. has write access, so I went ahead and pushed 
this to the trunk.

jeff


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 4/5] gcc/nios2: Define the musl linker
  2021-10-27 20:05 ` [PATCH 4/5] gcc/nios2: Define the musl linker Richard Purdie
@ 2021-10-28 14:46   ` Jeff Law
  0 siblings, 0 replies; 20+ messages in thread
From: Jeff Law @ 2021-10-28 14:46 UTC (permalink / raw)
  To: Richard Purdie, gcc-patches



On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> 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
THanks.  I've pushed this to the trunk

jeff


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-10-27 20:05 ` [PATCH 3/5] gcc: Add --nostdlib++ option Richard Purdie
  2021-10-27 20:56   ` Bernhard Reutner-Fischer
@ 2021-10-28 14:51   ` Jeff Law
  2021-10-28 16:39     ` Richard Purdie
  1 sibling, 1 reply; 20+ messages in thread
From: Jeff Law @ 2021-10-28 14:51 UTC (permalink / raw)
  To: Richard Purdie, gcc-patches



On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> 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
Couldn't you use -nostdlib then explicitly add -lgcc?

If that works, that would seem better to me compared to adding an option 
to specs processing that is really only useful to one build 
system/procedure.

jeff


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-10-28 14:51   ` Jeff Law
@ 2021-10-28 16:39     ` Richard Purdie
  2021-12-03  3:04       ` Jeff Law
  0 siblings, 1 reply; 20+ messages in thread
From: Richard Purdie @ 2021-10-28 16:39 UTC (permalink / raw)
  To: Jeff Law, gcc-patches

On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote:
> 
> On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> > 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
> Couldn't you use -nostdlib then explicitly add -lgcc?
> 
> If that works, that would seem better to me compared to adding an option 
> to specs processing that is really only useful to one build 
> system/procedure.

It sounds great in principle but I've never been able to get it to work. With 
"-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ -
nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the
resulting library doesn't link into applications correctly.

Cheers,

Richard


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-10-27 20:56   ` Bernhard Reutner-Fischer
@ 2021-10-28 16:41     ` Richard Purdie
  2021-12-03  3:05       ` Jeff Law
  0 siblings, 1 reply; 20+ messages in thread
From: Richard Purdie @ 2021-10-28 16:41 UTC (permalink / raw)
  To: Bernhard Reutner-Fischer, Richard Purdie via Gcc-patches

On Wed, 2021-10-27 at 22:56 +0200, Bernhard Reutner-Fischer wrote:
> On Wed, 27 Oct 2021 21:05:03 +0100
> Richard Purdie via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> 
> > 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.
> 
> But shouldn't it be called --nostdlibc++ then?

Maybe :). There are already --nostdinc++ and nostdlib options so --nostdlib++
matches those but I'm happy to use --nostdlibc++ if that is preferred.

Cheers,

Richard


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 2/5] gcc: Fix "argument list too long" from install-plugins
  2021-10-27 20:05 ` [PATCH 2/5] gcc: Fix "argument list too long" from install-plugins Richard Purdie
  2021-10-27 20:54   ` Bernhard Reutner-Fischer
@ 2021-12-03  3:01   ` Jeff Law
  1 sibling, 0 replies; 20+ messages in thread
From: Jeff Law @ 2021-12-03  3:01 UTC (permalink / raw)
  To: Richard Purdie, gcc-patches



On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> 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>
Thanks.  I've pushed this to the trunk.  Sorry about the long wait.
jeff

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-10-28 16:39     ` Richard Purdie
@ 2021-12-03  3:04       ` Jeff Law
  2021-12-05 11:43         ` Richard Purdie
  0 siblings, 1 reply; 20+ messages in thread
From: Jeff Law @ 2021-12-03  3:04 UTC (permalink / raw)
  To: Richard Purdie, gcc-patches



On 10/28/2021 10:39 AM, Richard Purdie wrote:
> On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote:
>> On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
>>> 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
>> Couldn't you use -nostdlib then explicitly add -lgcc?
>>
>> If that works, that would seem better to me compared to adding an option
>> to specs processing that is really only useful to one build
>> system/procedure.
> It sounds great in principle but I've never been able to get it to work. With
> "-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ -
> nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the
> resulting library doesn't link into applications correctly.
Can you be more specific about "doesn't link into applications 
correctly".  I'm still hesitant to add another option if we can 
reasonably avoid it.

jeff

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-10-28 16:41     ` Richard Purdie
@ 2021-12-03  3:05       ` Jeff Law
  0 siblings, 0 replies; 20+ messages in thread
From: Jeff Law @ 2021-12-03  3:05 UTC (permalink / raw)
  To: Richard Purdie, Bernhard Reutner-Fischer, Richard Purdie via Gcc-patches



On 10/28/2021 10:41 AM, Richard Purdie via Gcc-patches wrote:
> On Wed, 2021-10-27 at 22:56 +0200, Bernhard Reutner-Fischer wrote:
>> On Wed, 27 Oct 2021 21:05:03 +0100
>> Richard Purdie via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>
>>> 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.
>> But shouldn't it be called --nostdlibc++ then?
> Maybe :). There are already --nostdinc++ and nostdlib options so --nostdlib++
> matches those but I'm happy to use --nostdlibc++ if that is preferred.
Given the existing options, if we go forward, I'm OK with --nostdlib++.

jeff

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-12-03  3:04       ` Jeff Law
@ 2021-12-05 11:43         ` Richard Purdie
  2021-12-06  6:10           ` Fāng-ruì Sòng
  0 siblings, 1 reply; 20+ messages in thread
From: Richard Purdie @ 2021-12-05 11:43 UTC (permalink / raw)
  To: Jeff Law, gcc-patches

On Thu, 2021-12-02 at 20:04 -0700, Jeff Law wrote:
> 
> On 10/28/2021 10:39 AM, Richard Purdie wrote:
> > On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote:
> > > On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> > > > 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
> > > Couldn't you use -nostdlib then explicitly add -lgcc?
> > > 
> > > If that works, that would seem better to me compared to adding an option
> > > to specs processing that is really only useful to one build
> > > system/procedure.
> > It sounds great in principle but I've never been able to get it to work. With
> > "-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ -
> > nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the
> > resulting library doesn't link into applications correctly.
> Can you be more specific about "doesn't link into applications 
> correctly".  I'm still hesitant to add another option if we can 
> reasonably avoid it.

I took a step back and had another look at what our build is doing and why we
need this. Our build builds the different components separately in many cases so
libstdc++ is built separately since that allows us to tune it to specific
targets whilst the core gcc is architecture specific.

When we run configure for libstdc++, we have to configure CXX. We can configure
it as:

CXX="${HOST_PREFIX}g++ -nostdinc++"

however that gives errors about a missing libstdc++ during configure tests (e.g.
the atomic ones) since the library isn't present yet and we're trying to build
it. When I last ran into this I added the nostdlib++ option to mirror the
stdinc++ one and this solved the problem.

Adding -lgcc doesn't seem to work, binaries using libstdc++ segfault on some
architectures (mips64 and ppc). I suspect this is a link ordering issue which we
have little control of from the CXX variable but I haven't got deeply into it as
I got the feeling it would be a pain to try and correct, we need the compiler's
automatic linking behaviour which you can't emulate from one commandline.

I did also try -nostdlib and -nodefaultlibs with various libraries added in but
it never seems to work well giving segfaults, again as I suspect the linking is
order specific.

Thinking about the problem from scratch again, I wondered if a dummy libstdc++
would be enough to make the configure tests work correctly. I've found that I
can do something like:

mkdir -p XXX/dummylib
touch XXX/dummylib/libstdc++.so
export CXX="${CXX} -nostdinc++ -LXXX/dummylib"

and the configure works correctly and the resulting libs don't segfault on
target.

This is a bit of a hack but probably no worse than some of the other things we
have to do to build so if you're not keen on the patch we could go with this. It
did seem at least worth discussing our use case though! :)

Cheers,

Richard





^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 3/5] gcc: Add --nostdlib++ option
  2021-12-05 11:43         ` Richard Purdie
@ 2021-12-06  6:10           ` Fāng-ruì Sòng
  0 siblings, 0 replies; 20+ messages in thread
From: Fāng-ruì Sòng @ 2021-12-06  6:10 UTC (permalink / raw)
  To: Richard Purdie; +Cc: Jeff Law, gcc-patches

On Sun, Dec 5, 2021 at 6:43 AM Richard Purdie via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Thu, 2021-12-02 at 20:04 -0700, Jeff Law wrote:
> >
> > On 10/28/2021 10:39 AM, Richard Purdie wrote:
> > > On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote:
> > > > On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> > > > > 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
> > > > Couldn't you use -nostdlib then explicitly add -lgcc?
> > > >
> > > > If that works, that would seem better to me compared to adding an option
> > > > to specs processing that is really only useful to one build
> > > > system/procedure.
> > > It sounds great in principle but I've never been able to get it to work. With
> > > "-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ -
> > > nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the
> > > resulting library doesn't link into applications correctly.
> > Can you be more specific about "doesn't link into applications
> > correctly".  I'm still hesitant to add another option if we can
> > reasonably avoid it.
>
> I took a step back and had another look at what our build is doing and why we
> need this. Our build builds the different components separately in many cases so
> libstdc++ is built separately since that allows us to tune it to specific
> targets whilst the core gcc is architecture specific.
>
> When we run configure for libstdc++, we have to configure CXX. We can configure
> it as:
>
> CXX="${HOST_PREFIX}g++ -nostdinc++"
>
> however that gives errors about a missing libstdc++ during configure tests (e.g.
> the atomic ones) since the library isn't present yet and we're trying to build
> it. When I last ran into this I added the nostdlib++ option to mirror the
> stdinc++ one and this solved the problem.
>
> Adding -lgcc doesn't seem to work, binaries using libstdc++ segfault on some
> architectures (mips64 and ppc). I suspect this is a link ordering issue which we
> have little control of from the CXX variable but I haven't got deeply into it as
> I got the feeling it would be a pain to try and correct, we need the compiler's
> automatic linking behaviour which you can't emulate from one commandline.
>
> I did also try -nostdlib and -nodefaultlibs with various libraries added in but
> it never seems to work well giving segfaults, again as I suspect the linking is
> order specific.
>
> Thinking about the problem from scratch again, I wondered if a dummy libstdc++
> would be enough to make the configure tests work correctly. I've found that I
> can do something like:
>
> mkdir -p XXX/dummylib
> touch XXX/dummylib/libstdc++.so
> export CXX="${CXX} -nostdinc++ -LXXX/dummylib"
>
> and the configure works correctly and the resulting libs don't segfault on
> target.
>
> This is a bit of a hack but probably no worse than some of the other things we
> have to do to build so if you're not keen on the patch we could go with this. It
> did seem at least worth discussing our use case though! :)
>
> Cheers,
>
> Richard
>

Drive-by: is -nostdlib++ is implemented, hope its semantics are
similar to clang -nostdlib++ (https://reviews.llvm.org/D35780 since
2017)

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH 5/5] gcc: Pass sysroot options to cpp for preprocessed source
  2021-10-27 20:05 ` [PATCH 5/5] gcc: Pass sysroot options to cpp for preprocessed source Richard Purdie
@ 2021-12-14 23:47   ` Jeff Law
  0 siblings, 0 replies; 20+ messages in thread
From: Jeff Law @ 2021-12-14 23:47 UTC (permalink / raw)
  To: Richard Purdie, gcc-patches



On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> OpenEmbedded/Yocto Project extensively uses the --sysroot support within gcc.
> We discovered that when compiling preprocessed source (.i or .ii files), the
> compiler will try and access the builtin sysroot location rather than the
> --sysroot option specified on the commandline. If access to that directory is
> permission denied (unreadable), gcc will error. This is particularly problematic
> when ccache is involved.
>
> This patch adds %I to the cpp-output spec macro so the default substitutions for
> -iprefix, -isystem, -isysroot happen and the correct sysroot is used.
>
> 2021-10-27 Richard Purdie <richard.purdie@linuxfoundation.org>
>
> gcc/cp/ChangeLog:
>
>      * lang-specs.h: Pass sysroot options to cpp for preprocessed source
>
> gcc/ChangeLog:
>
>      * gcc.c: Pass sysroot options to cpp for preprocessed source
So generally OK, though I think this is incomplete.  If I understand the 
underlying bits correctly a similar change is needed in:

{lto,objc,fortran,ada/gcc-interface,objcp}/lang-specs.h.

I think d/lang-specs.h is OK, though it'd probably be useful to double 
check that.

jeff


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2021-12-14 23:48 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-27 20:05 [PATCH 0/5] OpenEmbedded/Yocto Project gcc patches Richard Purdie
2021-10-27 20:05 ` [PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets Richard Purdie
2021-10-28  7:04   ` Richard Biener
2021-10-28 14:43     ` Jeff Law
2021-10-27 20:05 ` [PATCH 2/5] gcc: Fix "argument list too long" from install-plugins Richard Purdie
2021-10-27 20:54   ` Bernhard Reutner-Fischer
2021-12-03  3:01   ` Jeff Law
2021-10-27 20:05 ` [PATCH 3/5] gcc: Add --nostdlib++ option Richard Purdie
2021-10-27 20:56   ` Bernhard Reutner-Fischer
2021-10-28 16:41     ` Richard Purdie
2021-12-03  3:05       ` Jeff Law
2021-10-28 14:51   ` Jeff Law
2021-10-28 16:39     ` Richard Purdie
2021-12-03  3:04       ` Jeff Law
2021-12-05 11:43         ` Richard Purdie
2021-12-06  6:10           ` Fāng-ruì Sòng
2021-10-27 20:05 ` [PATCH 4/5] gcc/nios2: Define the musl linker Richard Purdie
2021-10-28 14:46   ` Jeff Law
2021-10-27 20:05 ` [PATCH 5/5] gcc: Pass sysroot options to cpp for preprocessed source Richard Purdie
2021-12-14 23:47   ` Jeff Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).