Bumping glibc requirements for the Rust toolchain

[aidanhs]

But I do favor the conservative attitude, not to rock the boat here without reason. It works, and a few users have spoken up that they want it, so I think it needs stronger motivation to change.

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.

For extremists, the musl toolchain is to the rescue.

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.

None of those arguments cover why it’s actually beneficial to make this change.

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.

[cuviper]

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.)

[aidanhs]

Precisely. Seems I need to work on my clarity when proposing things.

[sfackler]

Oh yeah, I would definitely be on board with a more modern platform if it can target the right glibc version!

[hsivonen]

However, the actual glibc version required ends up being 2.3.4

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.)

[ishitatsuyuki]

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.

[ishitatsuyuki]

By this, do you mean some modern base image with cross-tools targeting a RHEL5-equivalent?

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.

[alexcrichton]

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.

[cuviper]

Unfortunately, there’s no maintained toolchain builder that can target glibc 2.5

You could still use CentOS binaries for glibc and kernel-headers, as I did for ppc64le here.

[eeeeeta]

How hard is it to get MUSL completely static rustc? Because that solves all sorts of problems, and is great for enterprise.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.