With Rust 1.89.0 the build went through just fine!
I suppose here "TLS" refers to thread-local storage rather than transport layer security
What is causing this? Is this a bug in rustc or in the OS?
Probably not a problem in my code, since the same code compiles (and runs) fine with Rust 1.94.1 (or 1.95.0) on various other OS, including Linux, Windows, macOS and FreeBSD.
Also I do not use thread_local! at all.
Anyways, is there any workaround, like specific rustc settings or changing my code?
This is libc failing to load rustc itself as it uses more TLS keys than libc has reserved in advance. I don't know why libc is not allocating new storage though. Maybe Haiku's libc simply doesn't implement that?
From what I understand, the maximum number of TLS (thread-local storage) keys is defined by PTHREAD_KEYS_MAX, i.e., the "Maximum number of data keys that can be created by a process".
It appears that this constant is platform-specific, but the POSIX standard defines the "Minimum Acceptable Value" as _POSIX_THREAD_KEYS_MAX – which is defined as 128.
So, this means that rustc probably should not use more than 128 TLS keys, because more than that is not guaranteed to be available. It would appear that Rust 1.94.1 violates this limit
Is there a reason why Rust 1.94.1 runs into this problem, while Rust 1.89.0 did not? Especially considering that my code has not changed, and that I don't even use thread_local!.
Or, maybe, is there some Rust configuration that can limit the number of required TLS keys?
The thing that would be relevant here is the number of thread_local!s in the code of rustc itself, not the code you are asking rustc to compile. There can’t be configuration to help because configuration can’t change what the code is.
The issue might be due to increased TLS storage used as part of the attribute refactor. This is speculation based on comments around here, not a confirmed cause.
Whatever the immediate cause, reigning in excessive TLS storage seems like a reasonable ask IMO.
