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

Promote i586-unknown-linux-gnu to Tier 2 with Host Tools #543

Closed
3 tasks done
goshhhy opened this issue Aug 11, 2022 · 3 comments
Closed
3 tasks done

Promote i586-unknown-linux-gnu to Tier 2 with Host Tools #543

goshhhy opened this issue Aug 11, 2022 · 3 comments
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@goshhhy
Copy link

goshhhy commented Aug 11, 2022 •
edited
Loading

Proposal

Promote the i586-unknown-linux-gnu target to Tier 2 with Host Tools.

Requirements for Tier 2 with Host Tools

Depending on the target, its capabilities, its performance, and the likelihood of use for any given tool, the host tools provided for a tier 2 target may include only rustc and cargo, or may include additional tools such as clippy and rustfmt.

This is not technically a requirement, but I would be satisfied to have only rustc and cargo.

Approval of host tools will take into account the additional time required to build the host tools, and the substantial additional storage required for the host tools.

The infrastructure team will have to comment on this.

The host tools must have direct value to people other than the target's maintainers. (It may still be a niche target, but the host tools must not be exclusively useful for an inherently closed group.) This requirement will be evaluated independently from the corresponding tier 2 requirement.

There must be a reasonable expectation that the host tools will be used, for purposes other than to prove that they can be used.

I am not a maintainer for this target, and I do not in fact directly use or contribute to Rust at all. I do sometimes do light maintenance work for Linux distributions, or build software myself, which results in indirect usage of Rust and software written in it.

I have computers that predate the Pentium 4, and the SSE2 instruction set. For some reason, rust defines the i686 target as meaning pentium4, despite that being i786 in other contexts, and i686 never having had SSE2 (see rust-lang/rust#82435). The suggestion I have received when asking about this is to use the i586 target instead. however, there are no host tools for i586, so I have no easy way to use Rust on my system.

Alpine Linux provides an i586-unknown-linux-musl version of Rust in its x86 port, and Debian patches its version of Rust so that i686 means pentium-pro, as has traditionally been the case. I prefer to use source-based distributions such as Gentoo or NixOS, but I cannot easily bootstrap Rust with either of those distributions on this system without having official host tools available.

At this point in time, Rust is now a de-facto requirement to be able to build a usable Linux distribution with a graphical environment, as several core dependencies have been rewritten to use Rust. Without this change, I am forced either to use old software, switch to a binary-based distro that provides a customized Rust toolchain, stop using Linux on my computers, or find a way - again, noting that I am an end user in this context, and not a developer - to cross-compile the toolchain on my own from another machine, as some others have before me.

this would nearly immediately benefit myself and others like me who, whether by choice (as i do) or by necessity (as i know factually that some others do), continue to use older hardware.

The host tools must build and run reliably in CI (for all components that Rust's CI considers mandatory), though they may or may not pass tests.

I believe the infrastructure team will have to address this.

Building host tools for the target must not take substantially longer than building host tools for other targets, and should not substantially raise the maintenance burden of the CI infrastructure.

My understanding from others who have built this target is that it does not take substantially more resources than the currently tier-1 i686-unknown-linux-gnu target.

The host tools must provide a substantively similar experience as on other targets, subject to reasonable target limitations.

I have no reason to believe that these tools would not provide a substantively similar experience to i686-unknown-linux-gnu, or to i586-unknown-linux-musl which is currently distributed and used by Alpine Linux (though is still Tier 2 here as well).

If the host tools for the platform would normally be expected to be signed or equivalent (e.g. if running unsigned binaries or similar involves a "developer mode" or an additional prompt), it must be possible for the Rust project's automated builds to apply the appropriate signature process, without any manual intervention by either Rust developers, target maintainers, or a third party. This process must meet the approval of the infrastructure team.

This target does not expect signed binaries.

Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible.

This target is already well-supported by cross compilation in my experience.

All requirements for tier 2 apply.

This target is already supported in Tier 2.

Mentors or Reviewers

None listed

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.
@goshhhy goshhhy added major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team labels Aug 11, 2022
@rustbot
Copy link
Collaborator

rustbot commented Aug 11, 2022

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

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Aug 11, 2022
goshhhy added a commit to goshhhy/rust that referenced this issue Aug 24, 2022
@goshhhy
lower baseline for i686 on unixlike targets
1778dc4 
this commit lowers the baseline for i686 from 'pentium4' to 'pentiumpro'
on the following targets to match their expected baseline for i686:

- i686-unknown-linux-gnu
- i686-unknown-linux-musl
- i686-unknown-freebsd
- i686-unknown-openbsd
- i686-unknown-netbsd
- i686-unknown-haiku

the pentium4 is not i686-class, and setting it as baseline results
in Rust using SSE2, which i686-class processors never had. this
change enables users of these platforms, with their expected
baseline, to use the upstream Rust host tools, and binaries built
for their platform. I fall into this category of users.

at least Debian and Gentoo have issues relating to this, and at least
Debian and FreeBSD patch Rust in order to make a similar change and
enable Rust to work correctly on their expected baseline. Users with
i686 hardware running distributions that do not distribute their own
modified toolchain are left unable to use Rust or software written
in it. as an aside, Rust is now a de-facto requirement to have a usable
GNU/Linux installation with a GUI.

Rust has an existing issue rust-lang#82435, which this patch
resolves; this patch also obviates the need for the MCP i filed as
rust-lang/compiler-team#543.

NetBSD (and i believe OpenBSD) normally targets i486 where possible,
and i586 where atomics make that difficult (which includes all Rust
programs); if targeting i686, these operating systems would also
expect a lower baseline than pentium4.

Haiku normally targets i586, but would also expect a lower baseline
than pentium4 for an i686 target.

Distributions such as Fedora which do not have a 32-bit version and
only use i686 for multilib can easily alter their build system to
enable SSE2, to match their expected baseline of x86_64 processors
running in 32-bit compatibility mode (all of which have SSE2).
@cuviper has expressed willingness to make this patch in Fedora.

Targets not changed are left as-is for the following reasons:

- Rust supports no earlier than Windows 7; Windows 7 and later all
  require SSE2, and so a minimum of Pentium 4 or similar.
- UEFI was not introduced until 2004 and not common until ~2011,
  well after the Pentium 4's heyday.
- I am aware of no scenario under which VxWorks would be running
  on a 32-bit x86 processor with a lower featureset than pentium4,
  unless it is a Vortex86, which is i586-class. even then, these
  would not be compiling programs for themselves, and the party
  building programs for that platform would have the ability to
  set target flags that make sense for their situation.
This was referenced Aug 24, 2022
Closed
Closed
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Aug 25, 2022
@nikic
Copy link
Contributor

nikic commented Feb 14, 2023

@rustbot second

I think the discussion on #548 has converged towards this option instead (see in particular the last comment). Assuming there is infra capacity, I don't think there is any reason not to provide host tools for this target.

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Feb 14, 2023
@apiraino
Copy link
Contributor

apiraino commented Mar 1, 2023

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

@apiraino apiraino closed this as completed Mar 1, 2023
@rustbot rustbot added major-change-accepted A major change proposal that was accepted to-announce Announce this issue on triage meeting and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Mar 1, 2023
@workingjubilee workingjubilee mentioned this issue Mar 3, 2023
Closed
goshhhy added a commit to goshhhy/rust that referenced this issue Mar 3, 2023
@goshhhy
promote i586-unknown-linux-gnu to Tier2+hosttools
1266e8d 
mcp: rust-lang/compiler-team#543
@goshhhy goshhhy mentioned this issue Mar 3, 2023
Closed
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@nikic @apiraino @goshhhy @rustbot