Build for RPi Zero, glibc 2.31 freezes in multilib step

[Lithimlin]

I'm currently trying to build a toolchain so I can compile for a Pi Zero.
The Zero has the following:

• OS and kernel: Raspbian 32bit, Linux 5.15.76+ armv6l
• glibc version: ldd (Debian GLIBC 2.31-13+rpt2+rpi1+deb11u5) 2.31

I have specified the version of glibc in the config and ever since when I try to build the chain, the process freezes in the multilib step without any indications as to why this is happening.
Before pulling down the glibc version I could build it just fine, but the compiled code didn't run on the Pi Zero due to the version mismatch.
I'm not sure if I'm missing further settings and would appreciate some help.

[...]
[INFO ]  =================================================================
[INFO ]  Installing kernel headers
[EXTRA]    Installing kernel headers
[INFO ]  Installing kernel headers: done in 9.66s (at 05:21)
[INFO ]  =================================================================
[INFO ]  Installing core C gcc compiler
[EXTRA]    Configuring core C gcc compiler
[EXTRA]    Building gcc
[EXTRA]    Installing gcc
[EXTRA]    Housekeeping for core gcc compiler
[EXTRA]       '' --> lib (gcc)   lib (os)
[INFO ]  Installing core C gcc compiler: done in 474.95s (at 13:16)
[INFO ]  =================================================================
[INFO ]  Installing C library
[INFO ]    =================================================================
[INFO ]    Building for multilib 1/1: ''
[EXTRA]      Configuring C library
[EXTRA]      Building C library
[15:20] -

• Crosstool-NG version: 1.25.0.124_0ce5b27
• Host OS and kernel: Arch Linux x86_64, 6.1.8-arch1-1
• Attach .config: config.txt
• Attach build.log: build.zip

[cpackham]

When you changed the glibc version did you start from fresh? There could be some left over build artifact from the earlier build that's interfering.

You can select CT_LOG_ALL to get (a lot) more output during the build, that'd help distinguish a genuine freeze from things just taking a while.

You might need to poke around with ps and/or strace to see what's going on when the build freezes. If there is some kind of deadlock or just way to much swapping going on you can set CT_PARALLEL_JOBS to a low number (like 1 or 2) which will make the builds less parallel.

[GrubbyHalo]

Yes I have experienced this as well. It looks like its active but it takes more than an hour to build and I have a fast machine. (I've always stopped it before it finished... if it ever does) . It doesn't seem to matter how many jobs i specify it always takes forever.

[Lithimlin]

When you changed the glibc version did you start from fresh?

I think so. It's been a while and I've since found another way to cross-compile my code.

[Bjoe]

Just for the sake of completeness, see issue #1932
From #1932 (comment)

There appears to be an infinite loop that glibc 2.19-2.25 exhibits on make v4.4+

[cpackham]

#1990 should have provided a workaround for this (as would downgrading the locally installe GNU make version). Closing for now