Update Rust version to 1.75

[chriskrycho]

We originally pinned to 1.63 because that was the last version before Rust dropped support for older versions of glibc in Rust 1.64. However, the relevant operating systems we were maintaining support for at that time (CentOS/RHEL 6) have now been end-of-life for three full years, so it seems reasonable to update to a more current version. Since no other changes to the glibc support have happened in the interval, we can safely update to the most current version of Rust.

As part of this, update the RHEL 7 Dockerfile setup for building on Rust 1.74, including using updated versions of gcc and binutils.

---

For discussion: is this breaking? I do not think we have written down our SemVer contract for things like this anywhere. It will break anyone who tries to update to what will presumably be Volta 1.2.0, so it may be appropriate (and is certainly simplest) to make it a 2.0.0 release, while noting that the only breakage is support for older versions.

[chriskrycho]

The one open question on this: should we use "stable" here instead, and only choose to pin a specific version if Rust releases a change that would affect our relationship to supported versions (#1619)?

[charlespierce]

I think keeping it set to a specific version is useful for reproducibility later on. That said, we can likely be more liberal with updating when we don't have issues with compatibility.

[charlespierce]

LGTM! It would be good to know (and probably document somewhere) the specific glibc versions that we now require, which is the ultimate compatibility question that will determine which versions of Linux we support. I don't have an easy way to test that at the moment, but with access to a linux machine I remember there being a command that would list out the specific dynamic library dependencies of the built Binary, so it should be doable using the artifacts from CI.

[neongreen]

docker run -it --platform linux/amd64 --volume ~/Downloads:/downloads ubuntu:latest
apt-get update
apt-get install binutils -y
cd /downloads
tar xf volta-linux.tar
objdump -T ./volta | grep GLIBC | sed 's/.*GLIBC_\([.0-9]*\).*/\1/g' | sort -Vu

Output:

2.2.5
2.3
2.3.4
2.4
2.9
2.12
2.14
2.15

Or with ldd:

ldd -v ./volta

	./volta:
		libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		librt.so.1 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/librt.so.1
		libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
		libpthread.so.0 (GLIBC_2.12) => /lib/x86_64-linux-gnu/libpthread.so.0
		libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
		libgcc_s.so.1 (GCC_3.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_4.2.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.3) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.9) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6

So I suppose 2.15 is the min version? But this doesn't match what Rust docs say

[neongreen]

This said, if you get ubuntu 12.04 (shipping with glibc 2.15), running ./volta does work:

docker run -it --platform linux/amd64 --volume ~/Downloads:/downloads ubuntu:12.04

[neongreen]

I suppose you might remain compatible with older glibc as long as you only use a subset of the standard library? But really not sure.

If that's the case, you'd have to check the min glibc version on CI, or just say that you support [whatever glibc your version of Rust supports] and make no promises about compatibility with earlier glibc versions.

[neongreen]

Regarding semver — I don't feel like bumping the minimum supported version is a semver violation, because eg. a distro maintainer might build your binary with musl, or even with an alternative Rust compiler, and it will work fine on older machines.

This said, there's a long long argument about it at semver/semver#716, so evidently there are people who think any breaking change counts as breaking the API.

[neongreen]

Unrelatedly, feel free to ping me on discord (@availablegreen) if you want me to check anything else re/ glibc

[chriskrycho]

Thanks so much for that info and input, @neongreen! We have some discussion over on #1619 for why we're inclined to treat the change as breaking. The TL;DR is that in practice, the change in MSRV will break any Fedora/RHEL users who rely on the pre-Rust 1.64 glibc version (or other distros), and who are committed to staying on those unsupported distro versions for whatever reason. Given SemVer is primarily a matter of keeping whatever contract we establish, we can ultimately do what we want here, but it seems best to just do the clearest thing in this case: flag it as a small breaking change. Especially since this is a binary, not a library, major versions are mostly free.