I'm absolutely not suggesting dropping support for RHEL 5 users and in general I too tend to be conservative. But since the boat has been rocked, we may as well talk about it.
They're not extremists, they're big businesses. And big businesses like to use things like NSS and internal crates.io mirrors - combining these two things won't work with musl. And, as has been mentioned, plugins won't work so you'll miss out on serde derive as well.
For me it's a recognition that we have to upgrade someday and that remaining on CentOS 5 imposes a non-zero maintenance burden, so why not do a compatibility-preserving upgrade now to benefit from an eased burden.
By this, do you mean some modern base image with cross-tools targeting a RHEL5-equivalent? That's less controversial, for sure. (and different than what @ishitatsuyuki was attempting.)
Is this meant to apply for x86/x86_64 only or is this meant to apply to other ISAs?
That is, is it a bug that Rust for big-endian 32-bit MIPS seems to have a higher glibc requirement?
/tmp/tmp.a7zWeNAkYp/rustup-init: /lib/mips-linux-gnu/libc.so.6: version `GLIBC_2.18' not found (required by /tmp/tmp.a7zWeNAkYp/rustup-init)
/tmp/tmp.a7zWeNAkYp/rustup-init: /lib/mips-linux-gnu/libc.so.6: version `GLIBC_2.16' not found (required by /tmp/tmp.a7zWeNAkYp/rustup-init)
(This is on Debian wheezy, which has glibc 2.13-38+deb7u10.)
No, it’s intended. Only the x86_64 and i686 Linux toolchains are built with compatibility options, since it would be impossible to bootstrap on older system if we broke them.
Unfortunately, there's no maintained toolchain builder that can target glibc 2.5, due to the significant maintenance burden. I wasn't able to build glibc 2.5, 2.6 and 2.11 on a modern system (glibc has non-standard conformant code and relied on compiler bugs), and I hesitate to try other old ones. crosstool-ng still have support for 2.12, while buildroot only supports the recent three versions.
Oh sorry thanks for asking @hsivonen, it’s definitely worth clarifying!
Right now all of the various platforms have different glibc requirements. Most of them are managed through a cross-compiled toolchain, however. We’ve got ubuntu 16.04 containers running crosstool-ng to compile a toolchain with an older glibc requirement. We tend to try to pick a glibc as old as possible.
Currently the mips builders however are just using the stock mips toolchains from Ubuntu 16.04, and as you can see they’re not “very old”! We would of course always accept a PR to use a custom toolchain! Configuration for one mips builder can be found at https://github.com/rust-lang/rust/blob/master/src/ci/docker/dist-mips-linux/Dockerfile and the others are in the same docker folder.