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.

[bjorn3]

FWIW cg_clif has supported raw-dylib for a while now and the standard library does use raw-dylib in one place. Is there anything else blocking full migration of the standard library to raw-dylib?

[ChrisDenton]

Seems there are still a few issue with raw-dylib https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20raw-dylib%20label%3AF-raw_dylib%20label%3AO-windows%2CO-windows-gnu%2CO-windows-msvc

It would be good if there were some stable way to override or rename std imports but there isn't yet.

[bjorn3]

It would be good if there were some stable way to override or rename std imports but there isn't yet.

What do you mean?

[ChrisDenton]

Currently if std has an extern block like:

#[link(name = "kernel32", kind = "raw-dylib")]
extern "C" { ... }

There's no way for the user to tell rustc to use kernel32.lib instead of generating a lib use raw-dylib (even without the raw-dylib, there's no way to rename or override std imports). If we had some mechanism for this, switching would be less fraught because there would be an opt-out.

[bjorn3]

Such an option would be incompatible with fixing #113050, right? AFAIK fixing #113050 would require mangling foreign items that use raw-dylib on the Rust side and then using the generated import library to redirect this to the right symbol in the target dll (similar to how we handle wasm_import_module). Opting-out of using the generated import library without recompiling the crate that uses raw-dylib is impossible if we do that.