Cross-compiling `raw-dylib` doesn't work on Windows

[mati865]

I tried this code:

#![feature(raw_dylib)]

fn main() {
    unsafe {
        MessageBoxA(0, b"hello\0".as_ptr(), "world\0".as_ptr(), 0);
    }
}

#[link(name = "user32", kind = "raw-dylib")]
extern "system" {
    fn MessageBoxA(hwnd: usize, lptext: *const u8, lpcaption: *const u8, flags: u32) -> i32;
}

I expected to see this happen:
Successful compilation

Instead, this happened:

$ PATH=/d/msys64/mingw32/bin:$PATH /c/Users/mateusz/.cargo/bin/rustc test.rs --target i686-pc-windows-gnu
error: Error calling dlltool: program not found

error: aborting due to previous error

Worth mentioning it works fine when building natively from x86_64 to x86_64 target.

Meta

rustc --version --verbose:

rustc 1.67.0-nightly (edf018221 2022-11-02)
binary: rustc
commit-hash: edf0182213a9e30982eb34f3925ddc4cf5ed3471
commit-date: 2022-11-02
host: x86_64-pc-windows-gnu
release: 1.67.0-nightly
LLVM version: 15.0.4

[bjorn3]

rust/compiler/rustc_codegen_llvm/src/back/archive.rs

Lines 404 to 409 in 31d754a

	// We are cross-compiling, so we need the tool with the prefix matching our target
	if sess.target.arch == "x86" {
	"i686-w64-mingw32-dlltool"
	} else {
	"x86_64-w64-mingw32-dlltool"
	}

Looks like rustc expects a toolchain that cross compiles from the host (x86_64 mingw) to the target (i686 mingw) rather than a toolchain native to the target (i686 mingw) like in your case. I guess it could try both executable names.

[mati865]

On Windows toolchains commonly provide only dlltool without prefix but it's possible to cross-generate import library using dlltool for any host with trick discovered by glandium: microsoft/windows-rs@cb8d6a9 (#2016)

[mati865]

I have it on my radar but cannot tell when when I can find free time to do it.

[dpaoliello]

@rustbot claim