32bit targets compiled with latest Buildroot & uClibc-ng on "stable" branch have broken sleep functions

[NadavTasher]

Due to a kernel incompatibility (< 5.1.0), uClibc-ng generates incorrect header files, which results in every clock_nanosleep syscall to use the 32 most-significant bits of the 64bit time_t tv_sec value of timespec to be used as seconds.

This only affects builds targeting 32bit systems (e.g. https://toolchains.bootlin.com/downloads/releases/toolchains/mips32/tarballs/mips32--uclibc--stable-2024.05-1.tar.xz).

[NadavTasher]

This is now checked for when compiling with uClibc-ng 1.0.51.

Builds should fail now.

[tpetazzoni]

So basically all that is needed at this point is that we rebuild toolchains with uClibc-ng 1.0.51 ?

[NadavTasher]

@tpetazzoni

No.

You can either lock the uClibc-ng version to a previous version (one released prior to TIME64 being introduced), or upgrade the stable version's kernel headers version to a newer version (That would probably have to be 5.4, since that's the closest LTS to 4.19)

Another approach could be to just disable TIME64 for 32bit targets, but that would cause too much inconsistencies when compiling other programs using the toolchains IMO.

[tpetazzoni]

You're saying lock the uClibc-ng version to a previous version, but isn't this issue fixed in uClibc-ng 1.0.51 that was recently released?

[NadavTasher]

No. It was not fixed in uClibc-ng 1.0.51.

The only thing that has changed is that now the build would fail when compiling with incompatible kernel headers (which would have prevented these broken toolchains from being released, had this check been introduced in time)

[tpetazzoni]

Ah, ok, it's clear now. So I guess the plan is to move the stable toolchains to kernel headers 5.4 as you suggested.

[NadavTasher]

Sounds like a solid plan.

I'd also suggest having another version of the toolchains called "legacy", which would have the latest binutils and GCC, and slightly older libc and kernel headers.
That would allow for better backwards compatibility with more embedded devices while maintaining the high standard of using the latest versions of GCC and binutils.

WDYT?

[tpetazzoni]

This is not very easy to do with how the toolchains are built today. They are built with Buildroot, which has a configurable version of GCC/binutils/GDB (within the last 3 releases) but not a configurable version of the C libraries. We could of course patch Buildroot, but reverting back seems a bit odd.

Which backward compatibility are you referring? Using a newer glibc is backward compatible with applications built with another glibc. uClibc has no binary compatibility anyway.

And when it comes to source-level compatibility, it's generally the upgrade of GCC that causes problems (because of stricter warnings/errors in newer versions).

Could you clarify the use-case/relevance ?

[NadavTasher]

For example, I have an older router at home, which runs a vendor customized version of Linux 2.6.

Bootlin does not currently offer toolchains that target such an old version of Linux, and while it's technically EOL for a very long time now, many devices still run it.

When compiling with newer versions of kernel headers, the libc uses features offered by these headers, making the toolchain backwards incompatible.
For example, namespaces are nowhere to be found in 2.6, and if I tried to run BusyBox compiled with a newer toolchain, it would SIGSEGV.

[tpetazzoni]

But that mostly needs to build toolchain with old headers, not old libc. This is actually why our "stable" toolchains are built with 4.19 headers, not something more recent, as people are unlikely to be running greatest-and-latest Linux (even if they should).

However, building a toolchain with modern components but headers as old as 2.6 is probably going to be very very challenging.

[NadavTasher]

But that mostly needs to build toolchain with old headers, not old libc.

This is right in theory, but as you can see from this very issue is that sometimes an older libc version is required.

I have already attempted compiling with older headers and it just works (tried with latest Buildroot a couple days back), but there could be more complexities when compiling for different architectures that I'm unaware of.

Should I try compiling toolchains using this repository and then open a PR?