Tracking issue for RFC 2627: #[link(kind="raw-dylib")] #58713

joshtriplett · 2019-02-24T23:10:49Z

🎉 RFC 2627 is now `#[link(kind="raw-dylib")]`! 🎉 Tracking issue: rust-lang/rust#58713

crlf0710 · 2019-02-27T08:41:01Z

ZerothLaw · 2019-03-02T16:14:13Z

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.)

@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

@Centril

Add feature gate for raw_dylib. This PR adds the feature gate for RFC 2627 (#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

@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

crlf0710 · 2019-10-08T05:17:24Z

A very first PR has landed, now the link_ordinal attribute is added. Want to say thank you to @Centril for helping me on this~

retep998 · 2020-04-20T04:40:05Z

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

est31 · 2020-04-20T23:35:41Z

Some information I've gathered:

The spec can be found here. It's a bit hard to understand in isolation as it's incomplete and some numbers are given in bits and others in bytes. You need to figure this out from other resources (see below).
We ONLY have to worry about the .idata section. Despite the syntax suggesting the opposite, the information is purely additive and doesn't change ANYTHING about the import itself (additional attribute in LLVM IR, etc). Roughly, .lib files that this feature wants to make unneccessary are condensed idata sections and the linker extracts the relevant ones for us. This is good for us because we don't need LLVM to support any custom attributes. Not tried it, but emitting additional sections should be enough, and there is LLVM API support for adding sections.
We'll have to generate not a single .idata section but rather multiple .idata$2, .idata$3, .idata$4, .idata$6, .idata$7 ones. See this part of the spec that explains the rationale
@SlugFiller has given a nice example in the original issue Produce idata content for dll/dylib import on windows #30027 in terms of llvm IR code what has to be done.
Basically, one "only" needs to create this IR code via the llvm API wrappers. The place for this is the librustc_codegen_llvm crate. One probably has to invoke the llvm::LLVMSetSection function in some fashion (just giving you something to grep for)
The current size check as of Add feature gate for raw_dylib. #63948 for the ordinals is too tolerant. The spec (section "import lookup table") only allocates 16 bits for both PE32 and PE32+.

To my best knowledge, these are the meanings of the .idata$* sections. See the spec/example for further understanding:

section	name in the MS spec	description
`.idata$2`	Import directory table	main list containing pointers into the other tables. Each entry in the list concerns one dll and contains pointers to the import address/lookup table, dll name table
`.idata$3`	Import Address Table	At compile time same as import lookup table. Just duplicate the output! Not sure whether it's actually `.idata$5`
`.idata$4`	Import Lookup Table	Has pointers to the function names
`.idata$6`	Hint/Name Table	Contains the names of the functions we want to import. Also contains export name table hints which are NOT the same as ordinals and we'll probably have to set to 0
`.idata$7`	No name in the MS spec, let's call it DLL name table	Contains the names for the dll files

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.

tinaun · 2020-04-22T22:47:16Z

that has been invaluable so far, thank you

luser · 2020-05-05T16:16:42Z

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:
https://github.com/apple/swift/blob/5d8af8ccf55f3d3dd7ad55dd8fbdc97d15c5b6bf/test/TBD/linking-with-tbd.swift
https://github.com/apple/swift/blob/5d8af8ccf55f3d3dd7ad55dd8fbdc97d15c5b6bf/lib/FrontendTool/TBD.cpp

retep998 · 2020-05-05T17:05:26Z

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))

dpaoliello · 2023-03-27T20:33:08Z

Request for Stabilization

I'd like to stabilize raw-dylib for all architectures (i.e., x86 as it is stabilized for all other architectures). A stabilization PR has been submitted as #109677.

Summary

The following four features will be stabilized:

The raw-dylib kind for the link attribute:

#[link(name = "exporter", kind = "raw-dylib")]
extern "stdcall" {
    fn imported_function_stdcall(i: i32);
}

The link_ordinal attribute:

#[link(name = "exporter", kind = "raw-dylib")]
extern "stdcall" {
    #[link_ordinal(15)]
    fn imported_function_stdcall(i: i32);
}

The import_name_type option for the link attribute:

#[link(name = "exporter", kind = "raw-dylib", import_name_type = "decorated")]
extern "stdcall" {
    fn imported_function_stdcall(i: i32);
}

The -Cdlltool codegen option:

rustc --crate-type lib lib.rs -Cdlltool=/path/to/dlltool

Documentation

I've submitted the following PRs:

Add docs to The Reference: Add documentation for raw-dylib and link_ordinal reference#1244
Update The Reference to remove note about the feature being unstable on x86 Windows: Update raw-dylib documentation for stabilization reference#1345

Tests

You can find test cases in:

run-make/raw-dylib-alt-calling-convention - x86 specific tests for different calling conventions.
run-make/raw-dylib-c - Basic tests of raw-dylib for all architectures, generating both a lib and a bin crate.
run-make/raw-dylib-cross-compilation - Tests cross-architecture compilation (specifically to validate uses of dlltool).
run-make/raw-dylib-custom-dlltool - Tests using -Cdlltool to use a custom dlltool.
run-make/raw-dylib-import-name-type - Tests the import_name_type link option to control how names are decorated on x86.
run-make/raw-dylib-inline-cross-dylib - Verifies that raw-dylib functions that are inlined into a different dynamic library are still generated and linked.
run-make/raw-dylib-link-ordinal - Basic tests of link_ordinal for all architectures.
run-make/raw-dylib-stdcall-ordinal - x86 specific tests for link_ordinal using an alternative calling convention.
ui/rfc-2627-raw-dylib/dlltool-failed.rs - Errors reported from dlltool are correctly propagated.
ui/rfc-2627-raw-dylib/import-name-type-invalid-format.rs - incorrect data type used in import_name_type option.
ui/rfc-2627-raw-dylib/import-name-type-multiple.rs - multiple import_name_type options.
ui/rfc-2627-raw-dylib/import-name-type-unknown-value.rs - unknown value provided to an import_name_type option.
ui/rfc-2627-raw-dylib/import-name-type-unsupported-link-kind.rs - import_name_type option use for non-raw-dylib link kind.
ui/rfc-2627-raw-dylib/import-name-type-x86-only.rs - import_name_type option used on non-x86 architecture.
ui/rfc-2627-raw-dylib/link-ordinal-and-name.rs - using link_ordinal with link_name results in an error.
ui/rfc-2627-raw-dylib/link-ordinal-invalid-format.rs - the ordinal provided to link_ordinal must be a number.
ui/rfc-2627-raw-dylib/link-ordinal-missing-argument.rs - an ordinal must be provided to link_ordinal.
ui/rfc-2627-raw-dylib/link-ordinal-multiple.rs - only one link_ordinal can be applied to a declaration.
ui/rfc-2627-raw-dylib/link-ordinal-not-foreign-fn.rs - link_ordinal used on a non-extern function.
ui/rfc-2627-raw-dylib/link-ordinal-too-large.rs - the ordinal provided to link_ordinal is too large.
ui/rfc-2627-raw-dylib/link-ordinal-too-many-arguments.rs - link_ordinal only takes a single argument.
ui/rfc-2627-raw-dylib/link-ordinal-unsupported-link-kind.rs - link_ordinal used on a non-raw-dylib link kind function.
ui/rfc-2627-raw-dylib/multiple-declarations.rs - clashing extern declarations with the raw-dylib link kind must have matching calling conventions.
ui/rfc-2627-raw-dylib/raw-dylib-windows-only.rs - raw-dylib may only be used when targeting Windows platforms.
ui/rfc-2627-raw-dylib/unsupported-abi.rs - raw-dylib only supports a subset of calling conventions per architecture.

Additionally, raw-dylib is supported in the windows-rs crate (microsoft/windows-rs#2164) and the windows-rs crate with raw-dylib support enabled is being used in the Rust compiler, bootstrap and compilertest (#106610).

Unresolved issues

None currently known.

simonbuchan · 2023-03-28T07:36:10Z

Now it's seemingly unblocked, for clarification, what would that last checklist item mean?

Implementation of a pure Rust target for Windows (no libc, no msvc, no mingw). This may require another RFC

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?

ChrisDenton · 2023-03-28T07:47:16Z

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.

simonbuchan · 2023-03-28T07:49:09Z

Don't disagree, but if I'm not missing something big that sounds like something I could take a stab at (no promises!)

ChrisDenton · 2023-03-28T08:00:28Z

Well I guess the big thing to implement would be panic handling. But being panic=abort only would be fine to start with.

…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)

top-master · 2023-05-18T06:10:55Z

I was redirected to here from:
https://users.rust-lang.org/t/can-i-compile-on-windows-using-nothing-but-the-llvm-toolchain/25683

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,
and it needs to be mixed either with MSVC or MingW to be a full compiler.

Said mixing is rather complicated, hence is worth an entire project of it's own, see:
https://github.com/mstorsjo/llvm-mingw

And at time of writting, linked project has ready to use releases for Windows, like:
llvm-mingw-20220906-msvcrt-i686.zip (117 MiB)

Long story short; rust may already support compiling with clang,
because there is a project that wraps clang into MingW, see above links.

ChrisDenton · 2023-05-18T08:10:07Z

We have *-pc-windows-gnullvm targets (currently tier 3) that use llvm with mingw.

Using llvm with msvc is tracked here: #71520. You can already replace msvc's link with lld-link, however libraries for panic handling and the C runtime are still required.

ChrisDenton · 2023-11-15T11:52:01Z

tl;dr I propose adding a "system" value to import_name_type.

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 import_name_type.

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 "system" value for import_name_type and allow setting it on all targets that support raw-dylib. E.g.:

// This works for all architectures
#[link(name="kernel32", kind="raw-dylib", import_name_type="system")]

dpaoliello · 2023-11-15T17:35:49Z

tl;dr I propose adding a "system" value to import_name_type.

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 import_name_type.

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 "system" value for import_name_type and allow setting it on all targets that support raw-dylib. E.g.:
// This works for all architectures
#[link(name="kernel32", kind="raw-dylib", import_name_type="system")]

If you're using raw-dylib, then you do need to be aware of name mangling, since you are opting out of using vendor-provided import libraries (which would have the correct names) and instead getting the Rust compiler to generate the mangled names itself from whatever information you provide.

I also don't believe that a system option for import_name_type would help, since system on x86 would decorate the name (it would be strange not to). Something like undecorate_on_x86 would be clearer and produce the behavior that you want but is a design dead-end.

Not supporting import_name_type outside of x86 was an explicit design choice for this feature to match #87678 rather than adding more debt for that item to clean up. In theory, Rust is moving to a model where using a feature that is unsupported on an arch results in an error rather than doing nothing - if that's something that you disagree with then I suggest you comment on #87678 or file an RFC so that we can have that discussion. If #87678 is adopted then you'll need to use macros anyway to get the correct calling convention on x86 so included import_name_type in that macro is moot.

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 import_name_type on ARM64EC will result in an error, and so making it meaningful later will not be a breaking change. If we had system, then we'd need to decide what it means ("to decorate, or not to decorate, that is the question" 🫴💀) and, if we get it wrong, changing it later would be a breaking change. If we went down the route of adding undecorate_on_x86 and then decide that undecorated on ARM64EC was the correct behavior, would we change the meaning of undecorate_on_x86 to include ARM64EC? Or create a new undecorate_on_x86_and_arm64ec then tell folks to migrate?

ChrisDenton · 2023-11-15T18:21:41Z

We already have extern "system" that means "pick the right calling convention for system imports". I don't think #87678 changes that? To be clear, I'm not proposing that import_name_type be ignored on x64, I'm proposing that setting it to the special "system" value means something analogous to the "system" calling convention (i.e. "pick the right name type for system imports"). I would be very surprised if the system import libraries (aka kernel32.lib, etc) would change their name mangling. This is stable and something that could be encoded with the target spec, no? Why force crates to have to figure it out for themselves?

Btw, ARM64EC is especially weird because its mangling scheme is to a prefix a # to the function name (e.g. #GetACP) which is unlike any of the current options we have for import_name_type.

Having a "system" import_name_type would also allow (along with extern system) raw-dylib system imports to just work without having to wait 6-12 months for crates to update their dependencies to use the latest bindings.

dpaoliello · 2023-11-15T19:17:58Z

We already have extern "system" that means "pick the right calling convention for system imports". I don't think #87678 changes that? To be clear, I'm not proposing that import_name_type be ignored on x64, I'm proposing that setting it to the special "system" value means something analogous to the "system" calling convention (i.e. "pick the right name type for system imports"). I would be very surprised if the system import libraries (aka kernel32.lib, etc) would change their name mangling. This is stable and something that could be encoded with the target spec, no? Why force crates to have to figure it out for themselves?

I wish that were true, but unfortunately it isn't the case. If you look at the docs for __cdecl is describes the name decoration as "Underscore character (_) is prefixed to names, except when __cdecl functions that use C linkage are exported." - so for extern "C" in Rust, do we decorate with _ or not?

Btw, ARM64EC is especially weird because its mangling scheme is to a prefix a # to the function name (e.g. #GetACP) which is unlike any of the current options we have for import_name_type.

I suspect we'll eventually want to support decorated (prefix with # which would link to the ARM64EC function) and undecorated (which would link to an x86_64 function), or we might add new options that explicitly state the arch of the function to decorate for. Either way, by not supporting it for now we can take our time to figure out what we want to support rather than being forced into a decision as soon as ARM64EC is added (and so changing it later would be a breaking change).

Having a "system" import_name_type would also allow (along with extern system) raw-dylib system imports to just work without having to wait 6-12 months for crates to update their dependencies to use the latest bindings.

I only really expect crates like winapi and windows-sys to use raw-dylib. It is an advanced feature that requires knowledge of calling conventions and decorations since you're taking full control of the name and shape of the function to call rather than relying on an import library. Anyone who thinks that they can simply replace dylib with raw-dylib is in for a world of pain (i.e., bizarre linking bugs and mismatched calling conventions).

joshtriplett added a commit to rust-lang/rfcs that referenced this issue Feb 24, 2019

Merge pull request #2627 from retep998/kindly-idata-my-dlls

528e0ae

🎉 RFC 2627 is now `#[link(kind="raw-dylib")]`! 🎉 Tracking issue: rust-lang/rust#58713

joshtriplett mentioned this issue Feb 24, 2019

#[link(kind="raw-dylib")] rust-lang/rfcs#2627

Merged

jonas-schievink added A-linkage Area: linking into static, shared libraries and binaries B-RFC-approved Feature: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Feb 24, 2019

Centril added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Feb 25, 2019

crlf0710 mentioned this issue Feb 27, 2019

Produce idata content for dll/dylib import on windows #30027

Closed

retep998 mentioned this issue Feb 27, 2019

Would it be possible to link xinput to 1.3 when 1.4 is not available retep998/winapi-rs#554

Open

retep998 mentioned this issue Mar 21, 2019

A way to reduce winapi-*-pc-windows-gnu? retep998/winapi-rs#754

Closed

MSxDOS mentioned this issue May 16, 2019

Use unions to represent unions retep998/winapi-rs#557

Open

retep998 mentioned this issue Jul 17, 2019

Changed handleapi feature link library from kernel32 to WindowsApp to… retep998/winapi-rs#782

Closed

RazrFalcon mentioned this issue Aug 10, 2019

Use custom bindings instead of winapi crate. danburkert/memmap-rs#89

Closed

crlf0710 mentioned this issue Aug 27, 2019

Add feature gate for raw_dylib. #63948

Merged

Centril added the F-raw_dylib `#![feature(raw_dylib)]` label Aug 27, 2019

retep998 mentioned this issue Sep 13, 2019

Don't get memcpy, memmove, memcmp, memset, and strlen from msvcrt.dll #29130

Closed

Lokathor mentioned this issue Mar 7, 2020

Tracking issue for improvements to Rust itself rust-windows/wg#3

Open

14 tasks

tinaun mentioned this issue Apr 24, 2020

[draft] Raw_dylib codegen #71497

Closed

6 tasks

est31 mentioned this issue Apr 28, 2020

cannot open input file 'deepspeech.lib' / Windows 10 RustAudio/deepspeech-rs#25

Open

This was referenced Mar 24, 2023

Stabilize -Cdlltool #109575

Closed

Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool #109677

Merged

This was referenced Apr 5, 2023

Strip .dll extension from raw-dylib link names microsoft/windows-rs#2431

Closed

Fix linker issues and target support Amanieu/parking_lot#378

Merged

filnet mentioned this issue Jun 3, 2023

rust: update to 1.70.0 msys2/MINGW-packages#17406

Merged

mon mentioned this issue Jun 26, 2023

#[link(kind="raw-dylib")] mis-compiles if cdylib export has the same name #113050

Open

wmmc88 mentioned this issue Sep 1, 2023

Ability to prevent linking of dlls microsoft/windows-rs#2640

Closed

novafacing mentioned this issue Jan 18, 2024

Consider raw dylibs for Windows novafacing/qemu-rs#8

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for RFC 2627: #[link(kind="raw-dylib")] #58713

Tracking issue for RFC 2627: #[link(kind="raw-dylib")] #58713

joshtriplett commented Feb 24, 2019 •

edited by ehuss

crlf0710 commented Feb 27, 2019

ZerothLaw commented Mar 2, 2019

crlf0710 commented Oct 8, 2019

retep998 commented Apr 20, 2020

est31 commented Apr 20, 2020 •

edited

tinaun commented Apr 22, 2020

luser commented May 5, 2020

retep998 commented May 5, 2020 •

edited

dpaoliello commented Mar 27, 2023 •

edited

simonbuchan commented Mar 28, 2023

ChrisDenton commented Mar 28, 2023

simonbuchan commented Mar 28, 2023

ChrisDenton commented Mar 28, 2023

top-master commented May 18, 2023 •

edited

ChrisDenton commented May 18, 2023

ChrisDenton commented Nov 15, 2023

dpaoliello commented Nov 15, 2023

ChrisDenton commented Nov 15, 2023

dpaoliello commented Nov 15, 2023

Tracking issue for RFC 2627: #[link(kind="raw-dylib")] #58713

Tracking issue for RFC 2627: #[link(kind="raw-dylib")] #58713

Comments

joshtriplett commented Feb 24, 2019 • edited by ehuss

crlf0710 commented Feb 27, 2019

ZerothLaw commented Mar 2, 2019

crlf0710 commented Oct 8, 2019

retep998 commented Apr 20, 2020

est31 commented Apr 20, 2020 • edited

tinaun commented Apr 22, 2020

luser commented May 5, 2020

retep998 commented May 5, 2020 • edited

dpaoliello commented Mar 27, 2023 • edited

Request for Stabilization

Summary

Documentation

Tests

Unresolved issues

simonbuchan commented Mar 28, 2023

ChrisDenton commented Mar 28, 2023

simonbuchan commented Mar 28, 2023

ChrisDenton commented Mar 28, 2023

top-master commented May 18, 2023 • edited

ChrisDenton commented May 18, 2023

ChrisDenton commented Nov 15, 2023

dpaoliello commented Nov 15, 2023

ChrisDenton commented Nov 15, 2023

dpaoliello commented Nov 15, 2023

joshtriplett commented Feb 24, 2019 •

edited by ehuss

est31 commented Apr 20, 2020 •

edited

retep998 commented May 5, 2020 •

edited

dpaoliello commented Mar 27, 2023 •

edited

top-master commented May 18, 2023 •

edited