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

[joshtriplett]

This is the tracking issue for RFC 2627, #[link(kind="raw-dylib")].

Note: raw-dylib and link_ordinal are now stabilized in 1.65 on Windows for x86_64, aarch64, and thumbv7a (not 32-bit x86) via #99916.

Opens:

• Implementation for Windows (top priority) (msvc: Partial support for raw-dylib linkage #84171) (gnu: Implement raw-dylib support for windows-gnu #90782)
  • Emitting idata sections
  • New link_ordinal attribute (Implement #[link_ordinal(n)] #89025)
  • Testing in winapi/windows-rs with nightly Rust before stabilization (Enables experimental support for raw-dylib microsoft/windows-rs#977 and Switch Direct2D sample to use raw-dylib microsoft/windows-samples-rs#18)
  • Supporting all calling conventions
    • cdecl
    • stdcall
    • fastcall
    • vectorcall
• Tests, including all the corner cases mentioned in the reference-level explanation
• Documentation (Add docs for raw-dylib to unstable book #87315)
• Implementation for Linux (Tracking Issue for raw-dylib on ELF #135694)
  • Stabilized?
• Implementation for macOS (Tracking Issue for raw_dylib_macho #146356)
  • Stabilized?
• Implementation for other platforms
• Implementation of a pure Rust target for Windows (no libc, no msvc, no mingw). This may require another RFC

[crlf0710]

cc rust-lang/rfcs#1061

[ZerothLaw]

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