Description
Proposal
This MCP generalizes -C prefer-dynamic so that one can specify a specific subset of the crates that should have the preferred-dynamic linkage.
In the past, one generally has to decide globally whether dynamic linkage will be preferred (via -C prefer-dynamic=on, or just -C prefer-dynamic) or if static linkage will be preferred (via -C prefer-dynamic=off, or just omitting the option entirely). The fact that this is a global choice means that one can get into tricky scenarios where, because of choices made by your crate dependencies for what output types they generate, combined with the internal heuristics used by rustc under -C prefer-dynamic that you have no control over, your crate hits strange linkage errors. (For one example of this, see rust-lang/rust#82151.)
There are multiple ways to address the above problem, such as changing the crate dependencies to reduce the kinds of output crate types they generate (see e.g. alexkornitzer/hyper@1199048), or choosing -C prefer-dynamic=no to stop rustc from injecting linkage directives, and then adding on additional RUSTFLAGS=-l<crate_name> flags to explicitly link to the dynamic libraries you want.
This MCP suggests a different way to address it: By allowing the user to specify a list of crates, -C prefer-dynamic=crate1,crate2,... they believe should be given preferred dynamic linkage.
A concrete PR has been developed illustrating how this works; see PR rust-lang/rust#88101.
Mentors or Reviewers
If you have a reviewer or mentor in mind for this work, mention then
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.