Description
Proposal
Ferrocene is going to ship some prebuilt libraries as part of its offering, and we need a way to make them available when invoking rustc. For most of those libraries, the easy solution will be to add the .rlib files (compiled as part of ./x) to the sysroot, so that --extern foo or extern crate foo; work as expected.
For some libraries though we need to ship multiple variants of it. The library that is prompting this is fairly hard to build and its source code is not public, but let's take reqwest as an example. You might want to ship reqwest prebuilt both with the native-tls feature and with the rustls-tls feature, so that users of your distribution can choose which prebuilt version to use. You cannot put both of them into the sysroot, as you'd encounter conflicts.
This MCP proposes a new variant for the -L flag: builtin:$path. The flag means $path is located inside of the distribution of rustc you are using. This would allow you to pass -L builtin:reqwest-native-tls or -L builtin:reqwest-rustls, without having to worry where in the distribution files the .rlibs are located.
In practice, builtin:$path will add lib/rustlib/$target/lib/builtin/$path inside of the sysroot to the search path, but this is an internal implementation detail that can change at any time (for example if the sysroot structure changes).
No builtin set of libraries is proposed to be shipped by the Rust project: this flag is meant to standardize how downstream distributions can provide such a feature.
The flag will be compatible with the kind of search path: -L all=builtin:foo or -L crate=builtin:bar will be supported.
Mentors or Reviewers
If you have a reviewer or mentor in mind for this work, mention them
here. You can put your own name here if you are planning to mentor the
work.
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.