Skip to content

Conversation

@davidtwco
Copy link
Member

@davidtwco davidtwco commented Oct 31, 2025

While Rust's pre-built standard library has proven itself sufficient for the majority of use cases, there are a handful of use cases that are not well supported:

  1. Rebuilding the standard library to match the user's profile
  2. Rebuilding the standard library with ABI-modifying flags
  3. Building the standard library for tier three targets

Proposals to solve these problems come broadly under the umbrella of "build-std" and date back over 10 years ago, though no complete solution has yet reached consensus.

This RFC does not propose any changes directly, only document the background, history and motivations for build-std. It is part of a series of build-std RFCs and later RFCs will reference this one. This RFC is part of the build-std project goal.

  1. build-std context (this RFC)
  2. build-std="always" (build-std: always #3874)
  3. Explicit standard library dependencies (build-std: explicit dependencies #3875)
  4. build-std="compatible" (RFC not opened yet)
  5. build-std="match-profile" (RFC not opened yet)

There is also a Zulip channel where you can ask questions about any of the build-std RFCs. This series of RFCs was drafted over many months with the help of stakeholders from many Rust project teams, we thank them for their help!

Rendered

@davidtwco davidtwco force-pushed the build-std-part-one-context branch from 8c857a0 to c8649ed Compare October 31, 2025 12:07
@davidtwco davidtwco added T-libs-api Relevant to the library API team, which will review and decide on the RFC. T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-cargo Relevant to the Cargo team, which will review and decide on the RFC. T-crates-io Relevant to the crates.io team, which will review and decide on the RFC. labels Oct 31, 2025
@Turbo87 Turbo87 moved this to For next meeting in crates.io team meetings Oct 31, 2025
@ehuss ehuss moved this to RFC needs review in Cargo status tracker Nov 4, 2025
@ehuss
Copy link
Contributor

ehuss commented Nov 13, 2025

I'm going to propose to go ahead and merge this RFC. Although it doesn't really have a distinct set of changes being defined, it does lay out the scope and intention of the direction we are planning to go.

I'd like to direct reviewers attention to the Motivation section as a key part of this RFC. It essentially outlines the key objectives and scope of this project. The following RFCs are explaining exactly how that will be achieved. The idea here is for us to agree that these are worthy goals and that we understand what's in and out of scope (in order to make this project tractable).

Getting this merged also helps with the subsequent RFCs which are built on top of this.

@rfcbot fcp merge compiler,cargo,crates-io,libs-api

@rust-rfcbot
Copy link
Collaborator

rust-rfcbot commented Nov 13, 2025

Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rust-rfcbot rust-rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Nov 13, 2025
> automated testing ensures that each tier 1 target builds and passes tests
> after each change.

As an innate property of the target, not all targets can support the `std` crate
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
As an innate property of the target, not all targets can support the `std` crate
As an innate property of the target, not all targets can support the `std` crate.

- There is no stable mechanism for using the standard library on a tier
three target that does not ship a pre-built std

- While it is common for these targets to not support the standard library,
Copy link
Member

Choose a reason for hiding this comment

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

I think you mean "std" here and not "the standard library", though it is quite common for tier 3 targets to support std. When scrolling through the list, most have an operating system and have had a working std build at some point. They do often break of course, something that build-std focused on tier 3 targets would likely need to address. That would be worth pointing out here I think, since it would have a significant effect, as either fixes would need to be backported to beta in time or the target would be unavailable for an entire cycle.
I happen have a bunch of (all of it) data on tier 3 breakage and would be happy to share that with anyone that wants to work on that :)


- Using miri requires building the standard library with specific compiler
flags that would not be appropriate for the pre-built standard library, so
is forced to require nightly and build its own sysroot
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this is what stops Miri from being stable. As part of the toolchain, Miri could do its sysroot building on stable just fine. The reason Miri isn't available on stable is because Rust has no stable memory model, so stable Miri could give users the impression that its assessment is in any way "final" and based on a stable memory model. So I don't think this use case is relevant here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. T-cargo Relevant to the Cargo team, which will review and decide on the RFC. T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-crates-io Relevant to the crates.io team, which will review and decide on the RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Projects

Status: RFC needs review
Archived in project

Development

Successfully merging this pull request may close these issues.

5 participants