-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 RFC 2627: #[link(kind="raw-dylib")] #58713
Comments
🎉 RFC 2627 is now `#[link(kind="raw-dylib")]`! 🎉 Tracking issue: rust-lang/rust#58713
I don't think I have the expertise to implement this feature, but I could write some (currently failing) tests for use by the implementor? (Background, Ran into this exact problem linking mscorlib.dll into executables. Had to write a C++ level wrapper to get it to work.) |
Add feature gate for raw_dylib. This PR adds the feature gate for RFC 2627 (rust-lang#58713). It doesn't contain the actual functionality. Add I'm not sure whether i did it correctly, since this is the first time i did this. r? @Centril
Add feature gate for raw_dylib. This PR adds the feature gate for RFC 2627 (rust-lang#58713). It doesn't contain the actual functionality. Add I'm not sure whether i did it correctly, since this is the first time i did this. r? @Centril
A very first PR has landed, now the |
There's now a bounty for this issue to incentivize someone to work on implementing this feature. https://www.bountysource.com/issues/70533351-tracking-issue-for-rfc-2627-link-kind-raw-dylib |
Some information I've gathered:
To my best knowledge, these are the meanings of the
The main table is the import directory table which contains pointers into the other tables. Linkers are smart enough to assemble all the relative pointers. As for who's implementing it, I've stopped contributing patches to the compiler years ago. Better someone else does it. Hope that with my help instructions and @retep998 's bounty there will be some movement on this. Of course I'm around to answer questions. |
that has been invaluable so far, thank you |
Just as a note about prior art, Apple stopped shipping .dylibs in their SDKs a while ago in favor of "TBD files" which are just YAML descriptions of shared libraries with enough information to link against them. Unfortunately they have zero actual documentation about them available, but the Swift compiler seems to support both generating and linking against them: |
Those "TBD files" are just the YAML equivalent of import libraries on Windows and are still separate files from the source code, so it isn't that novel. |
Fix cross-compiling with dlltool for raw-dylib Fix for rust-lang#103939 Issue Details: When attempting to cross-compile using the `raw-dylib` feature and the GNU toolchain, rustc would attempt to find a cross-compiling version of dlltool (e.g., `i686-w64-mingw32-dlltool`). The has two issues 1) on Windows dlltool is always `dlltool` (no cross-compiling named versions exist) and 2) it only supported compiling to i686 and x86_64 resulting in ARM 32 and 64 compiling as x86_64. Fix Details: * On Windows always use the normal `dlltool` binary. * Add the ARM64 cross-compiling dlltool name (support for this is coming: https://sourceware.org/bugzilla/show_bug.cgi?id=29964) * Provide the `-m` argument to dlltool to indicate the target machine type. (This is the first of two PRs to fix the remaining issues for the `raw-dylib` feature (rust-lang#58713) that is blocking stabilization (rust-lang#104218))
Request for StabilizationI'd like to stabilize SummaryThe following four features will be stabilized:
rustc --crate-type lib lib.rs -Cdlltool=/path/to/dlltool DocumentationI've submitted the following PRs:
TestsYou can find test cases in:
Additionally, Unresolved issuesNone currently known. |
Now it's seemingly unblocked, for clarification, what would that last checklist item mean?
Given that seems to want a break from msvc or whatever CRT compatibility, would that, other than the literal adding the target, mean "just" adding branches to std that call windows-rs (or equivalent I guess) for sys impls and not initializing the CRT? At least the former seems like it could be unconditional on windows (not sure if eg. gnu wants anything special) and the latter seems like a small change? |
I think it would require a new target or at least significant changes elsewhere. And that is beyond the scope of this feature. It could be tracked separately if someone is interested in pushing that forward. |
Don't disagree, but if I'm not missing something big that sounds like something I could take a stab at (no promises!) |
Well I guess the big thing to implement would be panic handling. But being |
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to `@tbu-` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to ``@tbu-`` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to ```@tbu-``` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to ````@tbu-```` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to `````@tbu-````` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to ``````@tbu-`````` for the first version of this PR (rust-lang#104218)
I was redirected to here from: There, people complain that MSVC is huge, and that they prefer clang (instead of MingW). But LLVM and/or clang is not yet (if ever) stand-alone for Windows, Said mixing is rather complicated, hence is worth an entire project of it's own, see: And at time of writting, linked project has ready to use releases for Windows, like: Long story short; |
We have Using llvm with msvc is tracked here: #71520. You can already replace msvc's |
tl;dr I propose adding a To illustrate the issue with the current MVP implementation, this works on x64 but not x86: #[link(name="kernel32", kind="raw-dylib")]
extern "system" {
fn GetLastError() -> u32;
} To make it work you have to know about name mangling and do: #[link(name="kernel32", kind="raw-dylib", import_name_type="undecorated")] But then this won't work on x64, so you'll need to make it conditional on the target arch. You'll likely end up using a macro to abstract over that, e.g. https://github.com/microsoft/windows-rs/blob/c70019f5126555754e02358758b5a24f2100db85/crates/libs/targets/src/lib.rs#L7-L31. This means that you not only have to know about name mangling but also you're forced to update the code when a new target is added. For example, if we got a ARM64EC target then we'd need to update the windows crate's raw-dylib macro to support the new I believe targets should already know how linking works for their target and not unnecessarily push that on the users of that target. Therefore I suggest adding a // This works for all architectures
#[link(name="kernel32", kind="raw-dylib", import_name_type="system")] |
If you're using I also don't believe that a Not supporting As for ARM64EC, when (not "if" 😉) we add support for that, then the current design gives us the space to decide how to support it: with the current design using |
We already have Btw, ARM64EC is especially weird because its mangling scheme is to a prefix a Having a "system" |
I wish that were true, but unfortunately it isn't the case. If you look at the docs for
I suspect we'll eventually want to support
I only really expect crates like |
This is the tracking issue for RFC 2627,
#[link(kind="raw-dylib")]
.Note:
raw-dylib
andlink_ordinal
are now stabilized in 1.65 on Windows for x86_64, aarch64, and thumbv7a (not 32-bit x86) via #99916.Opens:
link_ordinal
attribute (Implement#[link_ordinal(n)]
#89025)The text was updated successfully, but these errors were encountered: