Tracking Issue for using `raw-dylib` in the standard library

[ChrisDenton]

With the raw-dylib feature close to finishing stabilization, it'd be great to start using it in the Windows parts of the standard library so that we're not dependent on finding a Windows SDK for builds.

This issue is to track progress towards this goal and any issues that may arise from using raw-dylib generated import libraries instead of user-supplied import libraries. However, in doing so it's important not to lose out on any features people may be relying on.

Things to investigate include how this interacts with the different crate-types (e.g. lib. dylib, staticlib, etc) and how this may affect different linking scenarios, e.g. linking a Rust staticlib into a C++ project that wants to override imports.

Note that this issue is about the standard library only. The standard library is somewhat unique in that it is distributed pre-built therefore there's very limited ability to configure its behaviour.

Steps / History

• raw-dylib stabilization: Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool #109677
• cg_clif support for raw-dylib Implement raw-dylib for Windows rustc_codegen_cranelift#1345
• Use raw-dylib in the standard library

I'm tentatively tagging this with t-compiler as well as t-libs as there may be issues that concern the implementation of raw-dylib.

Unresolved Questions

• How is staticlib linking affected?

[ChrisDenton]

Of the crate-types I think only staticlib is materially affected. On the upside it would no longer require native libs to be linked in but on the other hand I think it makes it so you can't easily replace the import libraries. I'm not sure if this is a problem.

The only other potential issue is around requiring dlltool for windows-gnu targets. Will that be an issue? Should we wait until that's no longer necessary? Edit: Support for raw-dylib without llvm or dlltool is necessary for cg_clif, Issue updated.

[simonbuchan]

Worth noting that the windows/-sys crate implements raw-dylib for all it's imports behind --cfg windows_raw_dylib
https://github.com/microsoft/windows-rs/blob/master/crates/libs/targets/src/lib.rs, so it seems one approach for this is to port the standard library to using windows-sys then simply flip the flag?

[ChrisDenton]

Switching to using raw-dylib for imports is the easy part. The hard part is implementing this for cranelift (rust-lang/rustc_codegen_cranelift#1345) and possibly for windows-gnu targets (so dlltool isn't necessary).

[simonbuchan]

That sounds more like it! I just spent some time generating .exe files with the object crate and even got fairly far linking in from .lib files (turns out writing a linker is less hard and more just really annoying), so maybe I should take a look.

[simonbuchan]

Put an early WIP up here, for those interested: rust-lang/rustc_codegen_cranelift#1414

Not working yet, but it seems very plausible?

[ChrisDenton]

Thanks! I took a brief glance and it seems to be going in the right direction. I'll take a proper look at it when I can.