Tracking Issue for using raw-dylib
in the standard library
#110489
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.
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 #109677cg_clif
support forraw-dylib
Implement raw-dylib for Windows rustc_codegen_cranelift#1345raw-dylib
in the standard libraryI'm tentatively tagging this with
t-compiler
as well ast-libs
as there may be issues that concern the implementation of raw-dylib.Unresolved Questions
staticlib
linking affected?The text was updated successfully, but these errors were encountered: