Tracking Issue for `-Z link-native-libraries`

[jieyouxu]

This is a tracking issue for the unstable rustc flag -Z link-native-libraries.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Open an MCP and have it accepted. At the time of impl, there was no such requirement.
• Implementation
  • Implement -Zlink-native-libraries #70095
• Adjust documentation (see instructions on rustc-dev-guide)
  • Document -Zlink-native-libraries #116213
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• What does this unstable rustc flag -Z link-native-libraries do, exactly?
• How does it relate to the stable #[link] attribute?
• What does this mean for the #[link] attribute (which is a stable attribute)?
• How does this unstable flag relate to -Z link-directives?

  Seems fine to me. Perhaps we should proactively remove the other Zlink-native-libraries flag as a "failed experiment"?

  I think we still need -Zlink-native-libraries to deal with prebuilt rlibs - ie, the sysroot libraries.
  Implement -Zlink-directives=yes/no #107675 (comment)

Implementation history

• Implement -Zlink-native-libraries #70095
• Document -Zlink-native-libraries #116213

Related links

• Add option to allow #[link] directives to be ignored #70093
• Implement -Zlink-native-libraries #70095
• Tracking Issue for -Z link-directives #134947

[ChrisDenton]

So link-native-libraries=no is interesting. It appears to entirely disable passing native libraries to the linker. And unlike other flags, it has a global effect. So if we have #[link(name = "something")] in the precompiled std then usually there's no way to stop something being passed to the linker. However, with this flag it is possible (at the cost of having to manually add back everything else). The effect is useful for build systems that want complete control of linking.

Personally, if we ever stabilize something like this, I'd want it to be a bit more fine grained. So you could remove or replace individual native libraries as well as removing everything. You can kinda do a rename today with -l oldname:newname. But that effect is local to the crate and only allows renaming and not removing.

[Ralith]

This flag is useful in combination with the buck2 build system, which specifies most libraries explicitly. However, it breaks std on Windows for the reasons outlined by above. Thanks to the example at #134918, I worked out that you need to compensate by passing [a subset of] the libs referenced from https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/windows/c/windows_sys.rs, where for each foo.dll you add -Clink-arg=foo.lib to the rustc command line.

This is probably all working as intended -- for a hermitic build, you might want to instead pass paths to specific versions of those libraries, too. Still, it was difficult to uncover.