On Fri, 12 Sep 2025, H.J. Lu wrote: > On Fri, Sep 12, 2025 at 7:50 AM Joseph Myers <josmy...@redhat.com> wrote: > > > This breaks building glibc with linker errors for some configurations in > > build-many-glibcs.py (loongarch64-linux-gnuf64 loongarch64-linux-gnusf > > m68k-linux-gnu-coldfire m68k-linux-gnu-coldfire-soft or1k-linux-gnu). > > > > Representative linker errors are as follows. Of course assertion failures > > indicate a linker bug as well, but if there really are mixtures of TLS and > > non-TLS references to the same symbol as suggested by the or1k-linux-gnu > > > How does mixing TLS and non-TLS references of the same symbol work? > X86 linker issues an error if it happens. It sounds like a glibc bug.
I think the or1k-linux-gnu linker error messages are wrong, since I can't find any actual non-TLS references in the object files despite what the linker claims. So I now suspect linker bugs handling LE TLS on the three architectures indicated, which were exposed by this GCC mainline change affecting the TLS models used. I've CC:ed the binutils maintainers for those affected targets that are maintained (loongarch, or1k). See https://gcc.gnu.org/pipermail/gcc-patches/2025-September/695255.html for the specific errors building glibc with GCC and binutils mainline for each target. I've also CC:ed the binutils and libc-alpha lists. Note that m68k binutils has had no maintainer listed since 2008. Maybe it's time to remove support for at least the ColdFire sub-target in glibc if not the entire m68k port, ColdFire in particular has other breakage from some long-unresolved GCC bug or bugs that frequently comes and goes as a result of other changes in GCC. -- Joseph S. Myers josmy...@redhat.com
