Description
Proposal
I propose to increase the minimum-supported system versions on Linux targets to kernel 3.2 and glibc 2.17.
The last major change in this area was rust-lang/rust#74163, which updated to a least common denominator of supported enterprise distros, using kernel 2.6.32 like RHEL 6 and glibc 2.11 like SLES 11 SP4.
More recently, rust-lang/rust#94361 increased s390x alone to glibc 2.12, matching RHEL 6. This was justified because SLES 11 SP4 will reach the end of its lifecycle soon, on March 31, 2022. On the other hand, RHEL 6 already passed its end of maintenance support on November 30, 2020, but I had been holding out on that support in Rust to due to my own needs for how RHEL 7 packages are built. I now withdraw that hold, so I think it's time to look at RHEL 7 and SLES 12 for minimum support.
For glibc, the minimum version is important for CI builds to have the desired compatibility in ELF symbol versions. RHEL 7 has glibc 2.17, while SLES 12 started with 2.19 and updated to 2.22 in SP2. Thus glibc 2.17 should be the minimum for compatibility.
For the kernel, it's less important what's in the build system, and more a matter of policy for what user APIs we'll actually use, both for new syscalls and for new flags to existing syscalls. RHEL 7 has kernel 3.10, while SLES 12 started with 3.12 and updated to 4.4 in SP2 and 4.12 in SP4. But I suggest kernel 3.2 as our minimum, because that's the current minimum requirement for glibc itself, and there's not much to be gained in user API between 3.2 and 3.10.
In our documented platform support, some of the linux-gnu targets already have higher glibc/kernel requirements than this, and I propose to leave those alone. For consistency in std libs implementation, all *-linux-* targets should ideally follow the same minimum kernel version, but most of the android, musl, and uclibc targets don't document their minimum at all yet. We should state broadly-applicable minimums near the top of that document, and only keep minimum statements on existing targets that differ.
Mentors or Reviewers
This MCP is mostly a target policy update for discussion, but doesn't need mentoring. I already have a local branch with most of the appropriate CI changes ready, and @Mark-Simulacrum will probably want to review that.
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.