Increase the minimum linux-gnu versions

[cuviper]

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 merge on either the MCP or the PR.
• 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.

[rustbot]

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.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[nikic]

@rustbot second, though I'm not entirely sure whether this qualifies as a "user-facing" change that needs a full team FCP.

[cuviper]

This involves tier 1 targets, whose policy says:

Raising the baseline expectations of a tier 1 target (such as the minimum CPU features or OS version required) requires the approval of the compiler and release teams, and should be widely communicated as well, but does not necessarily require a full RFC.

So I think we do need a compiler+release FCP, and the change should at least be mentioned in the release notes.

[apiraino]

@rustbot label -final-comment-period +major-change-accepted