Pre-built Rust/musl toolchain improvements

[vazub]

Currently, the pre-built Rust/musl toolchain links against libgcc_s and libstdc++ dynamically, with an assumption that these libraries would be present in any Linux distro. This assumtion is wrong, and causes all sorts of pain for users who don't have those, for example on distro's that use toolchains other than GCC (LLVM, Zig etc.).

Request: provide pre-built Rust/musl toolchains with libgcc_s and libstdc++ compiled in statically. Or better yet, compile those toolchains against static compiler_rt and libc++.

[bjorn3]

libgcc_s is used for the system unwinder. There can only be a single unwinder in the entire process for the unwinder to be able to find all unwind tables (including those registered dynamically).

with an assumption that these libraries would be present in any Linux distro. This assumtion is wrong, and causes all sorts of pain for users who don't have those, for example on distro's that use toolchains other than GCC (LLVM, Zig etc.).

To be fair, libgcc_s is part of the LSB so it is reasonable to expect it to exist on Linux distros: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/app-libgcc-s.html

Or better yet, compile those toolchains against static compiler_rt and libc++.

Linking against compiler-rt wouldn't help at all as it doesn't provide an unwinder. Instead you did need LLVM libunwind. Assuming the distro in question where you have this problem is https://tangled.org/bazub.zubko.cc/mimicOS, this doesn't have a dynamically linked libunwind either, so switching to libunwind wouldn't help you.

It should be possible to statically link libstdc++ though. We do this on x86_64-unknown-linux-gnu already. I don't know why we don't on musl.

[vazub]

Thanks for clarification, @bjorn3 ! Technical limitations you describe make sense.

Actually, your second suggestion regarding dynamically linked LLVM libunwind would be very acceptable for the use case I pursue.

In summary, linking Rust toolchain against:

• musl (dynamically)
• LLVM libunwind (dynamically)
• LLVM compiler_rt (statically)
• LLVM libc++ (statically)

That would be an acceptable solution to the original request. This does not necessarily need to replace the current toolchain build target - could be a distinct one, even if for x86_64 only, experimentally. But I would guess that it will become quite popular once supported, especially due to tighter binding to LLVM project, instead of GCC.