Description
Proposal
I propose to update all currently supported musl targets to use musl 1.2.3 instead of musl 1.1.24. musl 1.1.24 was released on October 13th, 2019 and is the last release in the end-of-life 1.1 series. The musl 1.2 series does not impose new requirements on Linux kernel version and is essentially a drop-in upgrade except for one thing: time64.
time64
musl 1.2.0 changes the definition of time_t, and thereby the definitions of all derived types, to be 64-bit across all archs. This and related changes are collectively referred to as "time64", and are necessary so that data types and functions dealing with time can represent time past early 2038, where the existing 32-bit type on 32-bit archs would overflow.
As a result, the libc crate is being updated with the corresponding time64 changes for the affected 32-bit targets. This change is API-breaking but work is ongoing to mitigate the ecosystem impact.
Affected Targets
This proposal covers the following targets:
| Target | Support Tier | Has time64 API Changes |
|---|---|---|
aarch64-unknown-linux-musl |
Tier 2 with Host Tools | No |
x86_64-unknown-linux-musl |
Tier 2 with Host Tools | No |
arm-unknown-linux-musleabi |
Tier 2 | Yes |
arm-unknown-linux-musleabihf |
Tier 2 | Yes |
armv5te-unknown-linux-musleabi |
Tier 2 | Yes |
armv7-unknown-linux-musleabi |
Tier 2 | Yes |
armv7-unknown-linux-musleabihf |
Tier 2 | Yes |
i586-unknown-linux-musl |
Tier 2 | Yes |
i686-unknown-linux-musl |
Tier 2 | Yes |
mips-unknown-linux-musl |
Tier 2 | Yes |
mips64-unknown-linux-muslabi64 |
Tier 2 | No |
mips64el-unknown-linux-muslabi64 |
Tier 2 | No |
mipsel-unknown-linux-musl |
Tier 2 | No |
hexagon-unknown-linux-musl |
Tier 3 | No |
mips64-openwrt-linux-musl |
Tier 3 | No |
powerpc-unknown-linux-musl |
Tier 3 | Yes |
powerpc64-unknown-linux-musl |
Tier 3 | No |
powerpc64le-unknown-linux-musl |
Tier 3 | No |
riscv32gc-unknown-linux-musl |
Tier 3 | No |
riscv64gc-unknown-linux-musl |
Tier 3 | No |
s390x-unknown-linux-musl |
Tier 3 | No |
thumbv7neon-unknown-linux-musleabihf |
Tier 3 | No |
Next Steps
Per the Target Tier Policy, this MCP expresses the intent of the compiler team to ship these changes but is not the only signoff required to do so. The PR which implements these changes to the targets will be FCP'd by T-compiler, T-infra and T-release while the libc changes will be FCP'd by T-libs. A blog post explaining the change, the rationale and the expected fallout will be written and published on the Rust blog coinciding with the merge of the implementation PR.
Mentors or Reviewers
This change does not require mentorship, just reviews from the usual teams.
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.
Activity