Richard Cobbe

@est31 > Right now, this feature is only partially supported on the `*-windows-gnu` target family, which has several targets listed as [tier 1](https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-1-with-host-tools). In order to use the feature, users...

> Eventually as rustc migrates to LLD, this problem has to be solved anyways, no? I assume so, yeah. I think the important question for now, however, is whether solving...

Status update: as before, we'd love to see this feature taken up by the winapi and windows-rs crates, to get some real-world experience with it. Since my last message, I've...

I'd been under the impression that, when running for a *-windows-msvc target, rustc actually invokes the MSVC linker to generate the final .EXE/.DLL/.RLIB/.LIB/whatever. Therefore, since Microsoft's LINK.EXE isn't available when...

Also note #93842.

I've discovered a problem with how this feature, as currently implemented, supports stdcall functions from certain DLLs on i686-pc-windows-msvc. (I don't yet know if this problem also affects i686-pc-windows-gnu; I'll...

> if you don't want to use the mangled name on the symbol import, you can use the `#[no_mangle]` or `#[link_name = "..."]` attribute on the `fn` item. I'll give...

> FTR mingw-w64 specifies `WaitForSingleObject@8` (leading `_` is automatically added on 32-bit platforms) in the `.def` file: https://gitlab.com/mati865/mingw-w64-mirror/-/blob/master/mingw-w64-crt/lib32/kernel32.def#L1543 This works with both GNU and LLVM toolchains (at least in MinGW...

@mati865 > Unfortunately I have zero knowledge about MSVC but I think regardless of using `dllexport` attribute or `.def` file the select symbols are exported the same way. Much to...

Update: I've found a way to invoke LLVM's `writeImportLibrary` in a way that works with libraries like kernel32.dll, so I think the primary technical hurdle here has been overcome. However,...