Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for using raw-dylib in the standard library #110489

Open
1 of 3 tasks
ChrisDenton opened this issue Apr 18, 2023 · 6 comments
Open
1 of 3 tasks

Tracking Issue for using raw-dylib in the standard library #110489

ChrisDenton opened this issue Apr 18, 2023 · 6 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@ChrisDenton
Copy link
Member

ChrisDenton commented Apr 18, 2023

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

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 ChrisDenton added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 18, 2023
@ChrisDenton
Copy link
Member Author

ChrisDenton commented Apr 18, 2023

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Contributor

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

Not working yet, but it seems very plausible?

@ChrisDenton
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants