[PATCH 1/2] newlib: fix preprocessor checks

[PATCH 1/2] newlib: fix preprocessor checks

[Mike Frysinger]

Restore the call to AC_NO_EXECUTABLES -- I naively assumed in commit
2e9aa5f56cc26a411014a7f788423c670cfb5646 ("newlib: update preprocessor
configure checks") that checking for a preprocessor would not involve
linking code.  Unfortunately, autoconf will implicitly check that the
compiler "works" before allowing it to be used, and that involves a
link test, and that fails because newlib provides the C library which
is needed to pass a link test.

There is some code in NEWLIB_CONFIGURE specifically to help mitigate
these, but it's not kicking in here for some reason, so let's just add
the AC_NO_EXECUTABLES call back until we can unwind that custom logic.

Additionally, we have to call AC_PROG_CPP explicitly.  This was being
invoked later on, but only in the use_libtool=yes codepath, and that
is almost never enabled.
---
 newlib/libc/configure    | 1206 +++++++++++++++++++++-----------------
 newlib/libc/configure.ac |    2 +
 newlib/libm/configure    | 1128 +++++++++++++++++++----------------
 newlib/libm/configure.ac |    2 +
 4 files changed, 1285 insertions(+), 1053 deletions(-)

diff --git a/newlib/libc/configure.ac b/newlib/libc/configure.ac
index 5d4dc7bf5600..4a0160a57d80 100644
--- a/newlib/libc/configure.ac
+++ b/newlib/libc/configure.ac
@@ -45,7 +45,9 @@ AC_ARG_ENABLE(newlib-retargetable-locking,
  esac],[newlib_retargetable_locking=no])
 AM_CONDITIONAL(NEWLIB_RETARGETABLE_LOCKING, test x$newlib_retargetable_locking = xyes)
 
+AC_NO_EXECUTABLES
 NEWLIB_CONFIGURE(..)
+AC_PROG_CPP
 
 AM_CONDITIONAL(NEWLIB_NANO_MALLOC, test x$newlib_nano_malloc = xyes)
 
diff --git a/newlib/libm/configure.ac b/newlib/libm/configure.ac
index e4611ed846dd..a03ea3872bd5 100644
--- a/newlib/libm/configure.ac
+++ b/newlib/libm/configure.ac
@@ -16,7 +16,9 @@ AM_CONDITIONAL(NEWLIB_HW_FP, test x$newlib_hw_fp = xtrue)
 dnl Can't be done in NEWLIB_CONFIGURE because that confuses automake. 
 AC_CONFIG_AUX_DIR(../..)
 
+AC_NO_EXECUTABLES
 NEWLIB_CONFIGURE(..)
+AC_PROG_CPP
 
 dnl We have to enable libtool after NEWLIB_CONFIGURE because if we try and
 dnl add it into NEWLIB_CONFIGURE, executable tests are made before the first
-- 
2.34.1

[PATCH 2/2] newlib: add AC_CACHE_CHECK sugar around preprocessor checks

[Mike Frysinger]

This isn't strictly necessary, but it makes for much clearer logs as
to what the target is doing, and provides cache vars for anyone who
wants to force the test a different way.
---
 newlib/libc/configure                  | 48 ++++++++++++++++++--------
 newlib/libc/machine/nds32/acinclude.m4 |  7 ++--
 newlib/libc/machine/sh/acinclude.m4    |  7 ++--
 newlib/libc/machine/spu/acinclude.m4   |  9 +++--
 newlib/libm/configure                  | 32 ++++++++++++-----
 newlib/libm/machine/nds32/acinclude.m4 | 14 ++++----
 6 files changed, 78 insertions(+), 39 deletions(-)

diff --git a/newlib/libc/machine/nds32/acinclude.m4 b/newlib/libc/machine/nds32/acinclude.m4
index 35c2afe992bf..ae8ea5d91ecf 100644
--- a/newlib/libc/machine/nds32/acinclude.m4
+++ b/newlib/libc/machine/nds32/acinclude.m4
@@ -1,10 +1,11 @@
 if test "${machine_dir}" = "nds32"; then
   dnl Use builtin macro to detect if this is for "AndeStar ISA V3m".
-  AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
+  AC_CACHE_CHECK([for nds32 V3M ISA], newlib_cv_nds32_isa_v3m, [dnl
+    AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
 [[#ifdef __NDS32_ISA_V3M__
 # error "This is nds32_isa_v3m."
 #endif
-]])], [is_nds32_isa_v3m="no"], [is_nds32_isa_v3m="yes"])
+]])], [newlib_cv_nds32_isa_v3m="no"], [newlib_cv_nds32_isa_v3m="yes"])])
 fi
 
-AM_CONDITIONAL(IS_NDS32_ISA_V3M, test "$is_nds32_isa_v3m" = "yes")
+AM_CONDITIONAL(IS_NDS32_ISA_V3M, test "$newlib_cv_nds32_isa_v3m" = "yes")
diff --git a/newlib/libc/machine/sh/acinclude.m4 b/newlib/libc/machine/sh/acinclude.m4
index 60af7b1f1135..66ec3b4e15ff 100644
--- a/newlib/libc/machine/sh/acinclude.m4
+++ b/newlib/libc/machine/sh/acinclude.m4
@@ -1,9 +1,10 @@
 if test "${machine_dir}" = "sh"; then
-  AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
+  AC_CACHE_CHECK([for SH5 (64-bit)], newlib_cv_sh64, [dnl
+    AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
 [[#if !defined(__SH5__)
 # error "not SH5"
 #endif
-]])], [have_sh64=yes], [have_sh64=no])
+]])], [newlib_cv_sh64=yes], [newlib_cv_sh64=no])])
 fi
 
-AM_CONDITIONAL(SH64, [test "$have_sh64" = yes])
+AM_CONDITIONAL(SH64, [test "$newlib_cv_sh64" = yes])
diff --git a/newlib/libc/machine/spu/acinclude.m4 b/newlib/libc/machine/spu/acinclude.m4
index 4e5fb363ce13..bca70e309d1f 100644
--- a/newlib/libc/machine/spu/acinclude.m4
+++ b/newlib/libc/machine/spu/acinclude.m4
@@ -1,10 +1,9 @@
 if test "${machine_dir}" = "spu"; then
-  AC_MSG_CHECKING([whether the compiler supports __ea])
-  AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
+  AC_CACHE_CHECK([whether the compiler supports __ea], newlib_cv_spu_compiler_has_ea, [dnl
+    AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
 [[#if !defined (__EA32__) && !defined (__EA64__)
 # error "__ea not supported"
 #endif
-]])], [spu_compiler_has_ea=yes], [spu_compiler_has_ea=no])
-  AC_MSG_RESULT($spu_compiler_has_ea)
+]])], [newlib_cv_spu_compiler_has_ea=yes], [newlib_cv_spu_compiler_has_ea=no])])
 fi
-AM_CONDITIONAL(HAVE_SPU_EA, test x${spu_compiler_has_ea} != xno)
+AM_CONDITIONAL(HAVE_SPU_EA, test "$newlib_cv_spu_compiler_has_ea" = yes)
diff --git a/newlib/libm/machine/nds32/acinclude.m4 b/newlib/libm/machine/nds32/acinclude.m4
index 6363df8a3c76..781fa914556d 100644
--- a/newlib/libm/machine/nds32/acinclude.m4
+++ b/newlib/libm/machine/nds32/acinclude.m4
@@ -1,17 +1,19 @@
 if test "${libm_machine_dir}" = "nds32"; then
   dnl Use builtin macro to detect if FPU extension support is on.
-  AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
+  AC_CACHE_CHECK([for nds32 FPU SP extension], newlib_cv_nds32_fpu_sp, [dnl
+    AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
 [[#if (__NDS32_EXT_FPU_SP__)
 # error "Has nds32 FPU SP extension support"
 #endif
-]])], [has_nds32_fpu_sp="no"], [has_nds32_fpu_sp="yes"])
+]])], [newlib_cv_nds32_fpu_sp="no"], [newlib_cv_nds32_fpu_sp="yes"])])
 
-  AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
+  AC_CACHE_CHECK([for nds32 FPU DP extension], newlib_cv_nds32_fpu_dp, [dnl
+    AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
 [[#if (__NDS32_EXT_FPU_DP__)
 # error "Has nds32 FPU DP extension support"
 #endif
-]])], [has_nds32_fpu_dp="no"], [has_nds32_fpu_dp="yes"])
+]])], [newlib_cv_nds32_fpu_dp="no"], [newlib_cv_nds32_fpu_dp="yes"])])
 fi
 
-AM_CONDITIONAL(HAS_NDS32_FPU_SP, test "$has_nds32_fpu_sp" = "yes")
-AM_CONDITIONAL(HAS_NDS32_FPU_DP, test "$has_nds32_fpu_dp" = "yes")
+AM_CONDITIONAL(HAS_NDS32_FPU_SP, test "$newlib_cv_nds32_fpu_sp" = "yes")
+AM_CONDITIONAL(HAS_NDS32_FPU_DP, test "$newlib_cv_nds32_fpu_dp" = "yes")
-- 
2.34.1

Re: nds broken by recent patches

[Jeff Law]

On 1/28/2022 3:18 AM, Mike Frysinger wrote:

> np.  if my changes break a target, feel free to kick it up and i'll take a
> look.  shouldn't be too hard as long as the port is healthy and binutils &
> gcc work properly.  just remember to highlight the exact tuple you're using
> so i don't have to try and guess for these esoteric targets.  i tried to use
> nds32-elf here and that doesn't work, so i had to dig through grep output to
> see that nds32le-elf seems to work.
Well, part of the problem is we've got multiple targets failing in many 
different ways.

For example, someone mucked up the compiler for or1k-elf at the same 
time you're doing your refactoring.  Now I've got a patch to fix the 
compiler ICE, *but* I'm also getting a crap-ton of new testsuite 
failures in the testsuite due to missing _init/_fini symbols.  I don't 
know yet if that's a newlib issue or something else mucked up on the 
compiler side.

The h8300-elf port in the last few days has started failing while 
building newlib with:

cp: cannot stat 'libc/crt0.o': No such file or directory

The iq-2000-elf port has started failing building newlib in the last few 
days with:

make[3]: *** No rule to make target 'configure', needed by 
'config.status'.  Stop.
make[3]: Leaving directory 
'/home/jlaw/jenkins/workspace/iq2000-elf/iq2000-elf-obj/newlib/iq2000-elf/libgloss/iq2000'
make[2]: *** [Makefile:132: stmp-bsp] Error 2


And there's others.  Some are definitely on the GCC side (arc failures 
for example) , but having so many things breaking at once is frustrating.

Jeff

Re: nds broken by recent patches

[Jeff Law]

Replying to myself...

On 1/28/2022 9:36 AM, Jeff Law wrote:
>
> For example, someone mucked up the compiler for or1k-elf at the same 
> time you're doing your refactoring.  Now I've got a patch to fix the 
> compiler ICE, *but* I'm also getting a crap-ton of new testsuite 
> failures in the testsuite due to missing _init/_fini symbols.  I don't 
> know yet if that's a newlib issue or something else mucked up on the 
> compiler side.
I think I've tracked this done.  The change to internalize 
HAVE_INITFINI_ARRAY wasn't complete.  It missed newlib.  Affects 
aarch64, arm, or1k and cris -elf ports.  I don't test for former pair, 
but I do test the latter pair.   or1k and cris fail differently. 
or1k-elf code fails to link, while cris-elf fails a few tests that rely 
on ctor/dtor support.

>
> The h8300-elf port in the last few days has started failing while 
> building newlib with:
>
> cp: cannot stat 'libc/crt0.o': No such file or directory
I think you fixed this today.  Thanks.  My test is still spinning, but 
it's well past the point where it was previously failing.

If you could take care of the nds32 stuff Mike, it'd be appreciated.  
We'll reset and see where things are.


Jeff

Re: nds broken by recent patches

[Stafford Horne]

On Fri, Jan 28, 2022 at 02:54:24PM -0700, Jeff Law wrote:
> Replying to myself...
> 
> On 1/28/2022 9:36 AM, Jeff Law wrote:
> > 
> > For example, someone mucked up the compiler for or1k-elf at the same
> > time you're doing your refactoring.  Now I've got a patch to fix the
> > compiler ICE, *but* I'm also getting a crap-ton of new testsuite
> > failures in the testsuite due to missing _init/_fini symbols.  I don't
> > know yet if that's a newlib issue or something else mucked up on the
> > compiler side.
> I think I've tracked this done.  The change to internalize
> HAVE_INITFINI_ARRAY wasn't complete.  It missed newlib.  Affects aarch64,
> arm, or1k and cris -elf ports.  I don't test for former pair, but I do test
> the latter pair.   or1k and cris fail differently. or1k-elf code fails to
> link, while cris-elf fails a few tests that rely on ctor/dtor support.

Is there anything I can help with here for or1k-elf?  Or was this something I
did wrong with ff7b7b894 ("libgloss: or1k: If available call the init for
init_array")?

I haven't rebuilt my newlib toolchain since last year or so.

-Stafford

Re: nds broken by recent patches

[Jeff Law]

On 1/28/2022 4:32 PM, Stafford Horne wrote:
> On Fri, Jan 28, 2022 at 02:54:24PM -0700, Jeff Law wrote:
>> Replying to myself...
>>
>> On 1/28/2022 9:36 AM, Jeff Law wrote:
>>> For example, someone mucked up the compiler for or1k-elf at the same
>>> time you're doing your refactoring.  Now I've got a patch to fix the
>>> compiler ICE, *but* I'm also getting a crap-ton of new testsuite
>>> failures in the testsuite due to missing _init/_fini symbols.  I don't
>>> know yet if that's a newlib issue or something else mucked up on the
>>> compiler side.
>> I think I've tracked this done.  The change to internalize
>> HAVE_INITFINI_ARRAY wasn't complete.  It missed newlib.  Affects aarch64,
>> arm, or1k and cris -elf ports.  I don't test for former pair, but I do test
>> the latter pair.   or1k and cris fail differently. or1k-elf code fails to
>> link, while cris-elf fails a few tests that rely on ctor/dtor support.
> Is there anything I can help with here for or1k-elf?  Or was this something I
> did wrong with ff7b7b894 ("libgloss: or1k: If available call the init for
> init_array")?
It's a trivial goof in some recent refactoring in newlib.

>
> I haven't rebuilt my newlib toolchain since last year or so.
Which raises an interesting set of questions.  Is or1k at a point where 
we can cross build glibc & the kernel using upstream bits?    Is qemu 
user mode emulation available?  The former pair would be a step forward 
from a testing standpoint.  If we had the latter too, then we could 
build a rootfs and do native 3-stage testing in a chroot.

jeff

Re: nds broken by recent patches

[Stafford Horne]

On Fri, Jan 28, 2022 at 05:58:46PM -0700, Jeff Law wrote:
> 
> 
> On 1/28/2022 4:32 PM, Stafford Horne wrote:
> > On Fri, Jan 28, 2022 at 02:54:24PM -0700, Jeff Law wrote:
> > > Replying to myself...
> > > 
> > > On 1/28/2022 9:36 AM, Jeff Law wrote:
> > > > For example, someone mucked up the compiler for or1k-elf at the same
> > > > time you're doing your refactoring.  Now I've got a patch to fix the
> > > > compiler ICE, *but* I'm also getting a crap-ton of new testsuite
> > > > failures in the testsuite due to missing _init/_fini symbols.  I don't
> > > > know yet if that's a newlib issue or something else mucked up on the
> > > > compiler side.
> > > I think I've tracked this done.  The change to internalize
> > > HAVE_INITFINI_ARRAY wasn't complete.  It missed newlib.  Affects aarch64,
> > > arm, or1k and cris -elf ports.  I don't test for former pair, but I do test
> > > the latter pair.   or1k and cris fail differently. or1k-elf code fails to
> > > link, while cris-elf fails a few tests that rely on ctor/dtor support.
> > Is there anything I can help with here for or1k-elf?  Or was this something I
> > did wrong with ff7b7b894 ("libgloss: or1k: If available call the init for
> > init_array")?
> It's a trivial goof in some recent refactoring in newlib.
> 
> > 
> > I haven't rebuilt my newlib toolchain since last year or so.
> Which raises an interesting set of questions.  Is or1k at a point where we
> can cross build glibc & the kernel using upstream bits?    Is qemu user mode
> emulation available?  The former pair would be a step forward from a testing
> standpoint.  If we had the latter too, then we could build a rootfs and do
> native 3-stage testing in a chroot.

Now that glibc is upstream I guess the answer is yes.

I have been building a buildroot using my glibc braches/now on master (maybe
some buildroot patches need to be upstreamed to tell buildroot or1k has glibc
support).

With that we can test using qemu user mode.  I used to use qemu user mode to test
the glibc test-suite but not all syscalls are emulated so there were some tests
that would fail.

-Stafford

Re: nds broken by recent patches

[Jeff Law]

On 1/28/2022 7:12 PM, Stafford Horne wrote:
> On Fri, Jan 28, 2022 at 05:58:46PM -0700, Jeff Law wrote:
>>
>> On 1/28/2022 4:32 PM, Stafford Horne wrote:
>>> On Fri, Jan 28, 2022 at 02:54:24PM -0700, Jeff Law wrote:
>>>> Replying to myself...
>>>>
>>>> On 1/28/2022 9:36 AM, Jeff Law wrote:
>>>>> For example, someone mucked up the compiler for or1k-elf at the same
>>>>> time you're doing your refactoring.  Now I've got a patch to fix the
>>>>> compiler ICE, *but* I'm also getting a crap-ton of new testsuite
>>>>> failures in the testsuite due to missing _init/_fini symbols.  I don't
>>>>> know yet if that's a newlib issue or something else mucked up on the
>>>>> compiler side.
>>>> I think I've tracked this done.  The change to internalize
>>>> HAVE_INITFINI_ARRAY wasn't complete.  It missed newlib.  Affects aarch64,
>>>> arm, or1k and cris -elf ports.  I don't test for former pair, but I do test
>>>> the latter pair.   or1k and cris fail differently. or1k-elf code fails to
>>>> link, while cris-elf fails a few tests that rely on ctor/dtor support.
>>> Is there anything I can help with here for or1k-elf?  Or was this something I
>>> did wrong with ff7b7b894 ("libgloss: or1k: If available call the init for
>>> init_array")?
>> It's a trivial goof in some recent refactoring in newlib.
>>
>>> I haven't rebuilt my newlib toolchain since last year or so.
>> Which raises an interesting set of questions.  Is or1k at a point where we
>> can cross build glibc & the kernel using upstream bits?    Is qemu user mode
>> emulation available?  The former pair would be a step forward from a testing
>> standpoint.  If we had the latter too, then we could build a rootfs and do
>> native 3-stage testing in a chroot.
> Now that glibc is upstream I guess the answer is yes.
>
> I have been building a buildroot using my glibc braches/now on master (maybe
> some buildroot patches need to be upstreamed to tell buildroot or1k has glibc
> support).
I don't use the builtroot project to construct mine.  Though perhaps I 
should ;-)

>
> With that we can test using qemu user mode.  I used to use qemu user mode to test
> the glibc test-suite but not all syscalls are emulated so there were some tests
> that would fail.
Yea, I'm much more concerned about testing GCC and 3-staging using qemu 
user mode & running the testsuite does a much more thorough job than 
just building newlib and running the gcc testsuite.

Thanks.  Clearly I've got a little project on the horizon.

jeff

[PATCH/committed] libgloss: update Makefile regen rules for merged arches

[Mike Frysinger]

For arches that had their configure merged into the top-level, make
sure they don't still depend on a subdir configure script that no
longer exists.  I had cleaned this up for some of the subdirs, but
these got lost in the shuffle.
---
 libgloss/iq2000/Makefile.in     | 7 ++-----
 libgloss/microblaze/Makefile.in | 7 ++-----
 libgloss/nios2/Makefile.in      | 7 ++-----
 libgloss/pa/Makefile.in         | 7 ++-----
 libgloss/sparc_leon/Makefile.in | 7 ++-----
 libgloss/visium/Makefile.in     | 7 ++-----
 6 files changed, 12 insertions(+), 30 deletions(-)

diff --git a/libgloss/iq2000/Makefile.in b/libgloss/iq2000/Makefile.in
index 21cc2869f510..52b38a3e9fde 100644
--- a/libgloss/iq2000/Makefile.in
+++ b/libgloss/iq2000/Makefile.in
@@ -142,8 +142,5 @@ ${CRT0}: ${srcdir}/crt0.S
 # target specific makefile fragment comes in here.
 @target_makefile_frag@
 
-Makefile: Makefile.in config.status @host_makefile_frag_path@ @target_makefile_frag_path@
-	$(SHELL) config.status
-
-config.status: configure
-	$(SHELL) config.status --recheck
+Makefile: Makefile.in ../config.status
+	cd .. && $(SHELL) config.status
diff --git a/libgloss/microblaze/Makefile.in b/libgloss/microblaze/Makefile.in
index fe04a08c93d2..670c16a46311 100644
--- a/libgloss/microblaze/Makefile.in
+++ b/libgloss/microblaze/Makefile.in
@@ -141,8 +141,5 @@ info doc dvi:
 install-info:
 clean-info:
 
-Makefile: Makefile.in config.status @host_makefile_frag_path@ @target_makefile_frag_path@ \
-	$(SHELL) config.status
-
-config.status: configure
-	$(SHELL) config.status --recheck
+Makefile: Makefile.in ../config.status
+	cd .. && $(SHELL) config.status
diff --git a/libgloss/nios2/Makefile.in b/libgloss/nios2/Makefile.in
index fd7e79f70b04..fe1ea6adadaa 100644
--- a/libgloss/nios2/Makefile.in
+++ b/libgloss/nios2/Makefile.in
@@ -111,8 +111,5 @@ info dvi doc:
 install-info:
 clean-info:
 
-Makefile: Makefile.in config.status @host_makefile_frag_path@ @target_makefile_frag_path@
-	$(SHELL) config.status
-
-config.status: configure
-	$(SHELL) config.status --recheck
+Makefile: Makefile.in ../config.status
+	cd .. && $(SHELL) config.status
diff --git a/libgloss/pa/Makefile.in b/libgloss/pa/Makefile.in
index 03323c3b855d..a26b332a6e94 100644
--- a/libgloss/pa/Makefile.in
+++ b/libgloss/pa/Makefile.in
@@ -149,8 +149,5 @@ op50nled.o: ${srcdir}/op50nled.c
 # target specific makefile fragment comes in here.
 @target_makefile_frag@
 
-Makefile: Makefile.in config.status @host_makefile_frag_path@ @target_makefile_frag_path@
-	$(SHELL) config.status
-
-config.status: configure
-	$(SHELL) config.status --recheck
+Makefile: Makefile.in ../config.status
+	cd .. && $(SHELL) config.status
diff --git a/libgloss/sparc_leon/Makefile.in b/libgloss/sparc_leon/Makefile.in
index 5cc1e5491ffc..d914009f138a 100644
--- a/libgloss/sparc_leon/Makefile.in
+++ b/libgloss/sparc_leon/Makefile.in
@@ -157,8 +157,5 @@ clean-info:
 # target specific makefile fragment comes in here.
 @target_makefile_frag@
 
-Makefile: Makefile.in config.status @host_makefile_frag_path@ @target_makefile_frag_path@
-	$(SHELL) config.status
-
-config.status: configure
-	$(SHELL) config.status --recheck
+Makefile: Makefile.in ../config.status
+	cd .. && $(SHELL) config.status
diff --git a/libgloss/visium/Makefile.in b/libgloss/visium/Makefile.in
index bd430b286c9d..2906977c5173 100644
--- a/libgloss/visium/Makefile.in
+++ b/libgloss/visium/Makefile.in
@@ -122,8 +122,5 @@ clean-info:
 # target specific makefile fragment comes in here.
 @target_makefile_frag@
 
-Makefile: Makefile.in config.status @host_makefile_frag_path@ @target_makefile_frag_path@
-	$(SHELL) config.status
-
-config.status: configure
-	$(SHELL) config.status --recheck
+Makefile: Makefile.in ../config.status
+	cd .. && $(SHELL) config.status
-- 
2.34.1

Re: nds broken by recent patches

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

On 28 Jan 2022 09:36, Jeff Law wrote:
> For example, someone mucked up the compiler for or1k-elf at the same
> time you're doing your refactoring.  Now I've got a patch to fix the
> compiler ICE, *but* I'm also getting a crap-ton of new testsuite
> failures in the testsuite due to missing _init/_fini symbols.  I don't
> know yet if that's a newlib issue or something else mucked up on the
> compiler side.

i had tried to run the newlib testsuite, but it didn't seem to work out
of the box.  is there some trick/docs i'm missing to make them work ?

> The h8300-elf port in the last few days has started failing while 
> building newlib with:
> 
> cp: cannot stat 'libc/crt0.o': No such file or directory

i pushed a fix for this, so retry latest please
https://sourceware.org/pipermail/newlib/2022/019024.html

> The iq-2000-elf port has started failing building newlib in the last few 
> days with:
> 
> make[3]: *** No rule to make target 'configure', needed by 
> 'config.status'.  Stop.
> make[3]: Leaving directory 
> '/home/jlaw/jenkins/workspace/iq2000-elf/iq2000-elf-obj/newlib/iq2000-elf/libgloss/iq2000'
> make[2]: *** [Makefile:132: stmp-bsp] Error 2

i sent+pushed a fix for this
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=580817ec0132265e6dfd0bb19b5deaf6b5866a35

> And there's others.  Some are definitely on the GCC side (arc failures 
> for example) , but having so many things breaking at once is frustrating.

if your CI builders are public, point me at them and i can flip through.
i should be able to identify many of the libgloss/newlib ones that were
my fault a bit quicker.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: nds broken by recent patches

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On 28 Jan 2022 14:54, Jeff Law wrote:
> On 1/28/2022 9:36 AM, Jeff Law wrote:
> > For example, someone mucked up the compiler for or1k-elf at the same 
> > time you're doing your refactoring.  Now I've got a patch to fix the 
> > compiler ICE, *but* I'm also getting a crap-ton of new testsuite 
> > failures in the testsuite due to missing _init/_fini symbols.  I don't 
> > know yet if that's a newlib issue or something else mucked up on the 
> > compiler side.
> 
> I think I've tracked this done.  The change to internalize 
> HAVE_INITFINI_ARRAY wasn't complete.  It missed newlib.  Affects 
> aarch64, arm, or1k and cris -elf ports.  I don't test for former pair, 
> but I do test the latter pair.   or1k and cris fail differently. 
> or1k-elf code fails to link, while cris-elf fails a few tests that rely 
> on ctor/dtor support.

thanks ... the expectation was that things outside of newlib weren't
relying on this, but i think it's prob OK for libgloss to.  not great,
but not entirely unreasonable.  not sure what you meant by "it missed
newlib" as your fix only touches libgloss.  assuming that was a thinko.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] newlib: fix preprocessor checks

[Corinna Vinschen]

On Jan 28 05:23, Mike Frysinger wrote:
> Restore the call to AC_NO_EXECUTABLES -- I naively assumed in commit
> 2e9aa5f56cc26a411014a7f788423c670cfb5646 ("newlib: update preprocessor
> configure checks") that checking for a preprocessor would not involve
> linking code.  Unfortunately, autoconf will implicitly check that the
> compiler "works" before allowing it to be used, and that involves a
> link test, and that fails because newlib provides the C library which
> is needed to pass a link test.
> 
> There is some code in NEWLIB_CONFIGURE specifically to help mitigate
> these, but it's not kicking in here for some reason, so let's just add
> the AC_NO_EXECUTABLES call back until we can unwind that custom logic.
> 
> Additionally, we have to call AC_PROG_CPP explicitly.  This was being
> invoked later on, but only in the use_libtool=yes codepath, and that
> is almost never enabled.
> ---
>  newlib/libc/configure    | 1206 +++++++++++++++++++++-----------------
>  newlib/libc/configure.ac |    2 +
>  newlib/libm/configure    | 1128 +++++++++++++++++++----------------
>  newlib/libm/configure.ac |    2 +
>  4 files changed, 1285 insertions(+), 1053 deletions(-)

LGTM


Thanks,
Corinna

Re: [PATCH 2/2] newlib: add AC_CACHE_CHECK sugar around preprocessor checks

[Corinna Vinschen]

On Jan 28 05:23, Mike Frysinger wrote:
> This isn't strictly necessary, but it makes for much clearer logs as
> to what the target is doing, and provides cache vars for anyone who
> wants to force the test a different way.
> ---
>  newlib/libc/configure                  | 48 ++++++++++++++++++--------
>  newlib/libc/machine/nds32/acinclude.m4 |  7 ++--
>  newlib/libc/machine/sh/acinclude.m4    |  7 ++--
>  newlib/libc/machine/spu/acinclude.m4   |  9 +++--
>  newlib/libm/configure                  | 32 ++++++++++++-----
>  newlib/libm/machine/nds32/acinclude.m4 | 14 ++++----
>  6 files changed, 78 insertions(+), 39 deletions(-)
> 
> diff --git a/newlib/libc/machine/nds32/acinclude.m4 b/newlib/libc/machine/nds32/acinclude.m4
> index 35c2afe992bf..ae8ea5d91ecf 100644
> --- a/newlib/libc/machine/nds32/acinclude.m4
> +++ b/newlib/libc/machine/nds32/acinclude.m4
> @@ -1,10 +1,11 @@
>  if test "${machine_dir}" = "nds32"; then
>    dnl Use builtin macro to detect if this is for "AndeStar ISA V3m".
> -  AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
> +  AC_CACHE_CHECK([for nds32 V3M ISA], newlib_cv_nds32_isa_v3m, [dnl
> +    AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
>  [[#ifdef __NDS32_ISA_V3M__
>  # error "This is nds32_isa_v3m."
>  #endif
> -]])], [is_nds32_isa_v3m="no"], [is_nds32_isa_v3m="yes"])
> +]])], [newlib_cv_nds32_isa_v3m="no"], [newlib_cv_nds32_isa_v3m="yes"])])
          ^^^^^^^^^^
          libc_cv, perhaps, to keep the number of changes smaller,
          depending on the outcome of the discussion you started in
	  https://sourceware.org/pipermail/newlib/2022/019018.html?


Corinna

Re: nds broken by recent patches

[R. Diez]

> i had tried to run the newlib testsuite, but it didn't seem to work out
> of the box.  is there some trick/docs i'm missing to make them work ?

The Newlib test suite is known to be broken since forever.

The right thing to do would be to make it fail straight away with an error message like "The test suite is known to be broken.".

This way, nobody else will scratch their heads and waste time posting questions about it, like it just happened to you.

Regards,
   rdiez

Re: nds broken by recent patches

[Jeff Law]

On 1/28/2022 10:13 PM, Mike Frysinger wrote:
> On 28 Jan 2022 09:36, Jeff Law wrote:
>> For example, someone mucked up the compiler for or1k-elf at the same
>> time you're doing your refactoring.  Now I've got a patch to fix the
>> compiler ICE, *but* I'm also getting a crap-ton of new testsuite
>> failures in the testsuite due to missing _init/_fini symbols.  I don't
>> know yet if that's a newlib issue or something else mucked up on the
>> compiler side.
> i had tried to run the newlib testsuite, but it didn't seem to work out
> of the box.  is there some trick/docs i'm missing to make them work ?
No idea.  I'm actually using the GCC testsuite.   The whole idea behind 
my tester is to catch GCC codegen issues closer to the point where 
they're introduced.  Of course for these embedded targets I need a C 
library & simulator.  Enter newlib and the old cygnus simulators....


So for a newlib target the sequence looks something like:

build & install binutils
build & install gcc & libgcc
build & install newlib
run gcc testsuite



>
>> The h8300-elf port in the last few days has started failing while
>> building newlib with:
>>
>> cp: cannot stat 'libc/crt0.o': No such file or directory
> i pushed a fix for this, so retry latest please
> https://sourceware.org/pipermail/newlib/2022/019024.html
Thanks.  I can confirm that's fixed.

>
>> The iq-2000-elf port has started failing building newlib in the last few
>> days with:
>>
>> make[3]: *** No rule to make target 'configure', needed by
>> 'config.status'.  Stop.
>> make[3]: Leaving directory
>> '/home/jlaw/jenkins/workspace/iq2000-elf/iq2000-elf-obj/newlib/iq2000-elf/libgloss/iq2000'
>> make[2]: *** [Makefile:132: stmp-bsp] Error 2
> i sent+pushed a fix for this
> https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=580817ec0132265e6dfd0bb19b5deaf6b5866a35
Also confirmed as fixed.

>
>> And there's others.  Some are definitely on the GCC side (arc failures
>> for example) , but having so many things breaking at once is frustrating.
> if your CI builders are public, point me at them and i can flip through.
> i should be able to identify many of the libgloss/newlib ones that were
> my fault a bit quicker.
At this point we've covered those which are obviously due to the 
newlib/libgloss changes.  The current failures have to be examined with 
a debugger.  For example, bfin-elf seems to be failing after

> commit 754f8def0dfeeb43afa5a96ad1971fd0ef02c419
> Author: Mike Frysinger <vapier@gentoo.org>
> Date:   Sun Jan 23 01:10:33 2022 -0500
>
>     libgloss: merge stub arch configure scripts up a level
>
>     For about half the ports, we don't need a subdir configure script.
>     They're using the config/default.m[ht] rules, and they aren't doing
>     any unique configure tests, so they exist just to pass top-level
>     settings down to create the arch Makefile.  We can just as easily
>     do that from the top-level Mkaefile directly and skip configure.
>
>     Most of the remaining configure scripts could be migrated up to
>     the top-level too, but that would require care in each subdir.
>     So let's be lazy and put that off to another day.
>
But the failure mode is it looks like libgloss/bfin/syscalls.c got 
mis-compiled, but you have to dig into a failed GCC testsuite binary 
with gdb to make that determination.  On a positive note, you may have 
fixed this issue this morning with:

> commit 4b0e66093c0b48d5c363cf17c45ad9bf88ae526c
> Author: Mike Frysinger <vapier@gentoo.org>
> Date:   Fri Jan 28 05:12:54 2022 -0500
>
>     newlib: fix preprocessor checks


Anyway, if you want to take a peek at the CI/CD system

http://gcc.gnu.org/jenkins

Jeff

Re: nds broken by recent patches

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

On 01 Feb 2022 10:25, Jeff Law wrote:
> Anyway, if you want to take a peek at the CI/CD system
> 
> http://gcc.gnu.org/jenkins

the v850e failure is my fault.  it's the same issue as arm-eabi:
https://sourceware.org/pipermail/newlib/2022/019053.html

hoping Jeff can provide a bit more context before i just push that change.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: nds broken by recent patches

[Jeff Law]

On 2/2/2022 3:23 AM, Mike Frysinger wrote:
> On 01 Feb 2022 10:25, Jeff Law wrote:
>> Anyway, if you want to take a peek at the CI/CD system
>>
>> http://gcc.gnu.org/jenkins
> the v850e failure is my fault.  it's the same issue as arm-eabi:
> https://sourceware.org/pipermail/newlib/2022/019053.html
ACK.

>
> hoping Jeff can provide a bit more context before i just push that change.
Different Jeff ;-)  I have no context on that change.

jeff

Re: libgloss multilib installs broken [was nds broken by recent patches]

[Jeff Law]

I must have tested the wrong thing as bfin-elf isn't working yet.  It 
doesn't help that I'm only looking at this for a few minutes before my 
workday starts...    At least now I  know what's going on.

The *build* is fine, things go south at *install* time.

bfin has a wide variety of multilibs and we're installing them into the 
wrong directories.


So I'm sitting in my build directory...

> [jlaw@dl360p newlib]$ find . -name libsim.a
> ./bfin-elf/libgloss/bfin/libsim.a
> ./bfin-elf/bf532-none/libgloss/bfin/libsim.a
> ./bfin-elf/bf532-none/mid-shared-library/libgloss/bfin/libsim.a
> ./bfin-elf/bf532-none/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a
> ./bfin-elf/bf532-none/msep-data/libgloss/bfin/libsim.a
> ./bfin-elf/bf532-none/mfdpic/libgloss/bfin/libsim.a
> ./bfin-elf/mid-shared-library/libgloss/bfin/libsim.a
> ./bfin-elf/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a
> ./bfin-elf/msep-data/libgloss/bfin/libsim.a
> ./bfin-elf/mfdpic/libgloss/bfin/libsim.a

As expected.  Now if I go into my install directory:

> find . -name libsim.a
> ./bfin-elf/lib/libsim.a

Egad.  It looks like they all got installed on top of each other in the 
wrong directory, effectively ignoring the multilib subdirectories.  A 
checksum quickly shows the version in the install directory is actually 
this one from the build directory:
> ./bfin-elf/bf532-none/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a


If I go look at the Makefile in the terminal directory it has this:


> # Multilib support variables.
> # TOP is used instead of MULTI{BUILD,SRC}TOP.
> MULTIDIRS =
> MULTISUBDIR =
[ ... ]

> install-sim:
>         ${mkinstalldirs} ${DESTDIR}${tooldir}/lib${MULTISUBDIR}
>         for x in ${SIM_CRT0} ${SIM_BSP} ${SIM_SCRIPTS}; do \
>          ${INSTALL_DATA} $$x 
> $(DESTDIR)${tooldir}/lib${MULTISUBDIR}/$$x || exit $$?; \
>         done

So, yea, no surprise that it installed into the wrong directory. I think 
this is the culprit patch:

> commit 754f8def0dfeeb43afa5a96ad1971fd0ef02c419
> Author: Mike Frysinger <vapier@gentoo.org>
> Date:   Sun Jan 23 01:10:33 2022 -0500
>
>     libgloss: merge stub arch configure scripts up a level
>
>     For about half the ports, we don't need a subdir configure script.
>     They're using the config/default.m[ht] rules, and they aren't doing
>     any unique configure tests, so they exist just to pass top-level
>     settings down to create the arch Makefile.  We can just as easily
>     do that from the top-level Mkaefile directly and skip configure.
>
>     Most of the remaining configure scripts could be migrated up to
>     the top-level too, but that would require care in each subdir.
>     So let's be lazy and put that off to another day.

Re: libgloss multilib installs broken [was nds broken by recent patches]

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]

On 03 Feb 2022 09:11, Jeff Law wrote:
> I must have tested the wrong thing as bfin-elf isn't working yet.  It 
> doesn't help that I'm only looking at this for a few minutes before my 
> workday starts...    At least now I  know what's going on.
> 
> The *build* is fine, things go south at *install* time.
> 
> bfin has a wide variety of multilibs and we're installing them into the 
> wrong directories.

well that's annoying.  i was actually testing this code path recently as part
of migrating libgloss to automake, and the install logic worked there, so i
guess i fixed this bug and didn't realize it.

> So I'm sitting in my build directory...
> 
> > [jlaw@dl360p newlib]$ find . -name libsim.a
> > ./bfin-elf/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/mid-shared-library/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/msep-data/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/mfdpic/libgloss/bfin/libsim.a
> > ./bfin-elf/mid-shared-library/libgloss/bfin/libsim.a
> > ./bfin-elf/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a
> > ./bfin-elf/msep-data/libgloss/bfin/libsim.a
> > ./bfin-elf/mfdpic/libgloss/bfin/libsim.a
> 
> As expected.  Now if I go into my install directory:
> 
> > find . -name libsim.a
> > ./bfin-elf/lib/libsim.a
> 
> Egad.  It looks like they all got installed on top of each other in the 
> wrong directory, effectively ignoring the multilib subdirectories.  A 
> checksum quickly shows the version in the install directory is actually 
> this one from the build directory:
> > ./bfin-elf/bf532-none/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a
> 
> 
> If I go look at the Makefile in the terminal directory it has this:
> 
> 
> > # Multilib support variables.
> > # TOP is used instead of MULTI{BUILD,SRC}TOP.
> > MULTIDIRS =
> > MULTISUBDIR =
> [ ... ]
> 
> > install-sim:
> >         ${mkinstalldirs} ${DESTDIR}${tooldir}/lib${MULTISUBDIR}
> >         for x in ${SIM_CRT0} ${SIM_BSP} ${SIM_SCRIPTS}; do \
> >          ${INSTALL_DATA} $$x 
> > $(DESTDIR)${tooldir}/lib${MULTISUBDIR}/$$x || exit $$?; \
> >         done
> 
> So, yea, no surprise that it installed into the wrong directory. I think 
> this is the culprit patch:
> 
> > commit 754f8def0dfeeb43afa5a96ad1971fd0ef02c419
> > Author: Mike Frysinger <vapier@gentoo.org>
> > Date:   Sun Jan 23 01:10:33 2022 -0500
> >
> >     libgloss: merge stub arch configure scripts up a level
> >
> >     For about half the ports, we don't need a subdir configure script.
> >     They're using the config/default.m[ht] rules, and they aren't doing
> >     any unique configure tests, so they exist just to pass top-level
> >     settings down to create the arch Makefile.  We can just as easily
> >     do that from the top-level Mkaefile directly and skip configure.
> >
> >     Most of the remaining configure scripts could be migrated up to
> >     the top-level too, but that would require care in each subdir.
> >     So let's be lazy and put that off to another day.

yeah, the config-ml.in logic only rewrites the MULTI* settings in the Makefile
that lives alongside the configure script.  when i removed those stub scripts,
it lost that rewrite logic since they were no longer the main Makefile.  it's
a bit easy to make work, albeit slightly hacky.  on the flip side, the code is
not needed when using non-recursive automake :).

afaict, this is only needed for libgloss because the MULTISUBDIR setting is
used only when installing things.  newlib doesn't install files directly out
of its subdirs ... only out of the top libc/libm dirs.  but i'll update my
local build & test logic to compare the full install tree to be sure.

thanks for tracking this down
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH] libgloss: restore multilib settings in subdir makefiles

[Mike Frysinger]

Commit 754f8def0dfeeb43afa5a96ad1971fd0ef02c419 ("libgloss: merge stub
arch configure scripts up a level") had an unintended side-effect: the
MULTI* variables in the Makefiles no longer get rewritten at configure
time in the subdirs.  Only the top-level Makefile still is.  This is
because the configure integration of multilib (both the way libgloss
did it manually and the way AM_ENABLE_MULTILIB does it) only rewrites
"Makefile".

We could try propagating the MULTI* variables from libgloss/Makefile
down via FLAGS_TO_PASS, but this runs into a limitation: the multilib
logic uses this variable to switch from libgloss/ to each multilib
libgloss/, and libgloss uses this variable to enter subdirectories.
The latter we want, but the former ends up overridding the Makefile
environment.  We could side-step that with some GNU Make directives,
but it feels like we're getting a bit too deep down the rabbit hole.

Instead, let's call config-ml.in ourselves for each subdir Makefile
that the top-level configure generates.  This restores the previous
behavior and should be less risky in general.

This logic should be unnecessary when/if we switch libgloss over to
a non-recursive Automake build (since all build+install settings are
in the single libgloss/Makefile), but it'll be a while before we can
land that rework, so let's fix this up now.
---
 libgloss/arm/configure    |  2 ++
 libgloss/arm/configure.ac |  4 +++-
 libgloss/configure        | 15 ++++++++++++++-
 libgloss/configure.ac     | 13 +++++++++++++
 4 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/libgloss/arm/configure b/libgloss/arm/configure
index 8e3866b567b4..84878afffae3 100755
--- a/libgloss/arm/configure
+++ b/libgloss/arm/configure
@@ -3926,6 +3926,8 @@ $as_echo X"$file" |
   done
 }
  ;;
+    "cpu-init/Makefile":F)     ac_file=cpu-init/Makefile . ${srcdir}/../../config-ml.in
+   ;;
     "default-1":C)
 # Only add multilib support code if we just rebuilt the top-level
 # Makefile.
diff --git a/libgloss/arm/configure.ac b/libgloss/arm/configure.ac
index 2b98b5453725..3d7ba7da15d6 100644
--- a/libgloss/arm/configure.ac
+++ b/libgloss/arm/configure.ac
@@ -62,7 +62,9 @@ AC_SUBST_FILE(host_makefile_frag)
 # Configure cpu init plug-ins
 if test -d "${srcdir}/cpu-init"; then
   subdirs="${subdirs} cpu-init"
-  AC_CONFIG_FILES([cpu-init/Makefile])
+  AC_CONFIG_FILES([cpu-init/Makefile], [dnl
+    ac_file=cpu-init/Makefile . ${srcdir}/../../config-ml.in
+  ])
   AC_SUBST(subdirs)
 fi
 
diff --git a/libgloss/configure b/libgloss/configure
index 3fc20d6a2ab8..64f08cf166e1 100755
--- a/libgloss/configure
+++ b/libgloss/configure
@@ -4794,6 +4794,9 @@ target_makefile_frag_path=$target_makefile_frag
 
 
 
+ac_config_commands="$ac_config_commands default-1"
+
+
 # Default to --enable-multilib
 # Check whether --enable-multilib was given.
 if test "${enable_multilib+set}" = set; then :
@@ -4829,7 +4832,7 @@ if test $cross_compiling = no && test $multilib = yes \
    cross_compiling=maybe
 fi
 
-ac_config_commands="$ac_config_commands default-1"
+ac_config_commands="$ac_config_commands default-2"
 
 
 ac_config_files="$ac_config_files Makefile"
@@ -5554,6 +5557,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 # INIT-COMMANDS
 #
 AMDEP_TRUE="$AMDEP_TRUE" ac_aux_dir="$ac_aux_dir"
+subdirs="$subdirs"
 
 srcdir="$srcdir"
 host="$host"
@@ -5618,6 +5622,7 @@ do
     "libnosys/Makefile") CONFIG_FILES="$CONFIG_FILES libnosys/Makefile" ;;
     "depfiles") CONFIG_COMMANDS="$CONFIG_COMMANDS depfiles" ;;
     "default-1") CONFIG_COMMANDS="$CONFIG_COMMANDS default-1" ;;
+    "default-2") CONFIG_COMMANDS="$CONFIG_COMMANDS default-2" ;;
     "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
@@ -6347,6 +6352,14 @@ $as_echo X"$file" |
 }
  ;;
     "default-1":C)
+for subdir in $subdirs; do
+  case " $CONFIG_FILES " in
+   *" $subdir/Makefile "*)
+     ac_file=$subdir/Makefile . ${multi_basedir}/config-ml.in
+     ;;
+  esac
+done ;;
+    "default-2":C)
 # Only add multilib support code if we just rebuilt the top-level
 # Makefile.
 case " $CONFIG_FILES " in
diff --git a/libgloss/configure.ac b/libgloss/configure.ac
index ac812c69bafb..1fa877729f9b 100644
--- a/libgloss/configure.ac
+++ b/libgloss/configure.ac
@@ -330,6 +330,19 @@ target_makefile_frag_path=$target_makefile_frag
 AC_SUBST(target_makefile_frag_path)
 AC_SUBST_FILE(target_makefile_frag)
 
+dnl AM_ENABLE_MULTILIB only processes the top-level Makefile, but we want the
+dnl multilib settings to propagate to all sub-Makefiles that we recurse into
+dnl too.  This can go away if we ever get rid of sub-Makefiles and only use
+dnl Automake + makefile include fragments.
+AC_OUTPUT_COMMANDS([
+for subdir in $subdirs; do
+  case " $CONFIG_FILES " in
+   *" $subdir/Makefile "*)
+     ac_file=$subdir/Makefile . ${multi_basedir}/config-ml.in
+     ;;
+  esac
+done], [subdirs="$subdirs"])
+
 AM_ENABLE_MULTILIB(, ..)
 
 AC_CONFIG_FILES([Makefile])
-- 
2.34.1

Re: libgloss multilib installs broken [was nds broken by recent patches]

[Jeff Law]

On 2/3/2022 10:45 PM, Mike Frysinger wrote:
> On 03 Feb 2022 09:11, Jeff Law wrote:
>> I must have tested the wrong thing as bfin-elf isn't working yet.  It
>> doesn't help that I'm only looking at this for a few minutes before my
>> workday starts...    At least now I  know what's going on.
>>
>> The *build* is fine, things go south at *install* time.
>>
>> bfin has a wide variety of multilibs and we're installing them into the
>> wrong directories.
> well that's annoying.  i was actually testing this code path recently as part
> of migrating libgloss to automake, and the install logic worked there, so i
> guess i fixed this bug and didn't realize it.
Saw you committed the fix for this over the weekend.  I can confirm that 
the bfin, visium, frv and c6x ports are happy again.  I had suspected 
they were all the same problem.

At this point there's nothing failing due to newlib/libgloss issues.  
Thanks for all the fixes.

jeff