Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Demote Apple 32bit targets to Tier 3 #2837

Merged
merged 1 commit into from
Dec 30, 2019
Merged

Demote Apple 32bit targets to Tier 3 #2837

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
125 changes: 125 additions & 0 deletions text/0000-demote-apple-32bit.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,125 @@
- Feature Name: `demote_apple_32bit`
- Start Date: 2019-12-10
- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)

# Summary
[summary]: #summary

This RFC proposes to demote the `i686-apple-darwin` rustc target from Tier 1 to
Tier 3, and to demote the `armv7-apple-ios`, `armv7s-apple-ios` and
`i386-apple-ios` rustc targets from Tier 2 to Tier 3.

# Motivation
[motivation]: #motivation

Apple [publicly announced][macos-announcement] that macOS 10.14 Mojave is the
last OS supporting the execution of 32bit binaries, and macOS 10.15 (and later)
prevents running them at all. It's been years since the last 32bit Apple
hardware was sold, so providing 64bit binaries should cover most of the macOS
userbase.

Apple [also announced][ios-announcement] that iOS 10 is the last one supporting
the execution of 32bit apps, and they won't work at all on iOS 11 and later.
All iPhones after the iPhone 5 and the iPhone 5C support 64bit apps, which
means all the supported ones can run them.

Along with the deprecation, Apple removed support for building 32bit binaries
since Xcode 10, and that makes building rustc itself on the project's CI harder
(as we're limited to providers still offering Xcode 9).

It makes little sense for the Rust team to continue providing support for a
platform the upstream vendor abandoned, especially when it requires extra
effort from us infrastructure-wise.

[macos-announcement]: https://support.apple.com/en-us/HT208436
[ios-announcement]: https://developer.apple.com/documentation/uikit/app_and_environment/updating_your_app_from_32-bit_to_64-bit_architecture

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

The first release after this RFC is merged will be the last one with Tier 1
support for the `i686-apple-darwin` target and Tier 2 support for the
`armv7-apple-ios`, `armv7s-apple-ios` and `i386-apple-ios` targets. The release
after that will demote the targets to Tier 3, which means no official build
will be available for them, and they will not be tested by CI.

Once this RFC is merged a blog post will be published on the main Rust Blog
announcing the change, to alert the users of the target of the demotion. The
demotion will also be mentioned in the release announcement for the last
release with Tier 1 and Tier 2 support, as well as the first release with Tier
3 support.

This RFC does **not** propose removing the targets completely from the
codebase: that will be decided either by another RFC just for those targets, or
by an RFC defining a general policy for Tier 3 target removal.

Once the targets are demoted to Tier 3, users on other platforms with one of
those targets' `rust-std` installed won't be able to update the toolchain until
they remove that target. Users using an Apple 32bit compiler as their host
platforms will instead be prevented from updating at all, as no new binary
artifact will be available.

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

The `i686-apple-darwin`, `armv7-apple-ios`, `armv7s-apple-ios` and
`i386-apple-ios` targets will be considered Tier 3 from the second release
after this RFC is merged. The code supporting the target will not be removed
from the compiler, even though we won't guarantee it will continue to work.

The following CI builders will be removed:

- `dist-i686-apple`
- `i686-apple`

In addition, the `armv7-apple-ios`, `armv7s-apple-ios` and `i386-apple-ios`
targets will be removed from the `dist-x86_64-apple` builder.

# Drawbacks
[drawbacks]: #drawbacks

Users might depend on the target, and approving this RFC means they'll be stuck
on an old compiler version forever, unless they build their own compiler and
fix the regressions introduced in newer releases themselves.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

Support for building 32bit binaries for Apple targets is shrinking as time goes
by: the latest SDKs from Apple don't support building them at all, and CI
providers are slowly starting to upgrade their minimum supported SDK versions:

* Azure Pipelines (the provider rustc currently use) doesn't have any public
information on when Xcode 9 will be deprecated.
* GitHub Actions doesn't support Xcode 9 at all.
* Travis CI [deprecated Xcode older than 9.2][travis-ci-xcode-deprecation] in
July 2018.

If this RFC is not accepted, we'll eventually reach a point when we'll have to
make considerable investments both in terms of money and time to keep building
on Apple 32bit.

[travis-ci-xcode-deprecation]: https://blog.travis-ci.com/2018-07-19-xcode9-4-default-announce

# Prior art
[prior-art]: #prior-art

There is no precedent inside the project for the deprecation of Tier 1 targets
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps the RFC should say more about the general procedure for this sort of thing?

The justification for demotion seems quite reasonable. But it seems unexpected to me that a tier 1 platform would suddenly become tier 3 from one release to another without much warning. I know demotion to tier 3 isn't "removal", but given the less than straightforward process currently of manually building an std targeting a tier 3 platform, it essentially is removal to typical users.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps the RFC should say more about the general procedure for this sort of thing?

I explicitly didn't want to include a general policy about demoting targets: I hope it will be addressed by #2803, and I don't want this RFC to get slowed down while we agree on such a policy.

The justification for demotion seems quite reasonable. But it seems unexpected to me that a tier 1 platform would suddenly become tier 3 from one release to another without much warning. I know demotion to tier 3 isn't "removal", but given the less than straightforward process currently of manually building an std targeting a tier 3 platform, it essentially is removal to typical users.

Unfortunately we don't have much choice on this, sooner or later we're going to have to demote these targets: Apple is actively trying to stop projects from supporting 32bit, as you can't even cross-compile 32bit binaries anymore starting from macOS 10.14.

We don't have any insight on the plans Azure Pipelines has about deprecating build platforms, but we don't expect them to continue providing macOS 10.13 builders forever. I don't expect other CI providers to support that platform after it reaches EOL either.

Once most of the providers offering macOS stop supporting 10.13 we'd then have to build our own build farm, with an out of date, unsupported and potentially vulnerable base OS. That would put even more workload on the already busy infrastructure team, and let's not consider the security risk of doing that.

Unless there are people who actively rely on Apple 32bit support, or other major blockers show up, I don't see why we shouldn't just demote the target soon.

And to be clear, we're happy to support older platforms when it's feasible: all the Linux x86/x86_64 toolchains are built inside a CentOS 5 container to keep supporting Linux 2.6.18, for example. It's just that we don't have the resources to do that if upstream tries to prevent people from doing so.

Copy link
Contributor

@gnzlbg gnzlbg Dec 12, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but given the less than straightforward process currently of manually building an std targeting a tier 3 platform, it essentially is removal to typical users.

Notice that the process is currently quite straightforward: cargo xbuild --target=i686-apple-darwin just works and would continue to work "as is" if these targets are demoted to tier 3. We use this in libc to build libcore and libc for pretty much most/all tier-1, tier-2 and tier-3 targets for which libc is a reasonable thing to build (including the ios targets mentioned here). This process should become simpler once cargo itself is made "std-aware", at which point you wouldn't even need cargo-xbuild.

Copy link

@ids1024 ids1024 Dec 12, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's great if it's that simple. But I thought cargo-xbuild doesn't support building std? This is mentioned in the CHANGELOG for release v0.4.0 (when it was forked from xargo): "Building std is no longer possible".

If I understand that correctly, and it hasn't changed since then (the README doesn't clearly indicate one way or the other), then I think my statement unfortunately still holds that it's not currently straightforward to use std on a tier 3 platform.

(Std-aware cargo should greatly improve this.)

to Tier 3.

Go is taking a [similar approach to us][go-34749], documenting that the last
release supporting Apple 32bit is going to be Go 1.14 (the next one), with
support for the target being dropped in Go 1.15.

[go-34749]: https://github.com/golang/go/issues/34749

# Unresolved questions
[unresolved-questions]: #unresolved-questions

*Nothing here.*

# Future possibilities
[future-possibilities]: #future-possibilities

*Nothing here.*