Linux -> Windows Cross Compilation broken

[abbec]

This change 198621c#diff-26e81435323b9d11b39a44aa6f5adf5b3d863e3b2b149d6c2777b925ca8694b9R53 seems to break cross-compilation from Linux. It seems the build script is run with the equivalent of cfg!(unix), not cfg!(windows).

[kennykerr]

Have you actually tried to build for Windows on Linux? I'm not sure that's ever worked. That would require libs for Windows that a Linux-based linker could use to resolve imports, not to mention a C++ compiler that can cross compile for Windows on Linux. Not saying that's not possible, but I'd be surprised if that worked before this change. Also, I would imagine this problem would eventually go away once DLL imports are implemented.

[kennykerr]

Anyway, I deal with the issue of the build script not necessarily using the target compiler by checking the CARGO_CFG_TARGET_ARCH environment variable when copying architecture-specific dependencies. We could in theory use the
CARGO_CFG_TARGET_OS environment variable in a similar way to identify the target OS if we end up supporting something like this, but I'm not sure that's going to be something we need to support.

[abbec]

Hmm what do you mean? We use a mingw cross compiler on Linux to build for Windows and that works fine (except for this crate). Using the winapi crate works but I thought I would give this one a try but if it is not supported for this crate then so be it :)

[kennykerr]

That works because the winapi crate generates its own lib files. The windows crate doesn't do that, but as we have folks working on DLL imports we will soon not need lib files at all. So yes, I'd love to support that scenario eventually.

[kennykerr]

I'll leave this open for now while noting that it is blocked on rust-lang/rust#58713.

[abbec]

Cool, thanks! :)

[ke1satsu]

Just wanted to continue my comments from issue #1073, I confirmed that in my particular case I was able to cross-compile a simple MessageBoxA testing project. (Compiled on Debian with mingw)

I symlinked like so:
ln -s /usr/x86_64-w64-mingw32/lib/libole32.a /usr/x86_64-w64-mingw32/lib/libOLE32.a
ln -s /usr/x86_64-w64-mingw32/lib/liboleaut32.a /usr/x86_64-w64-mingw32/lib/libOLEAUT32.a
ln -s /usr/x86_64-w64-mingw32/lib/libuser32.a /usr/x86_64-w64-mingw32/lib/libUSER32.a
ln -s /usr/x86_64-w64-mingw32/lib/libkernel32.a /usr/x86_64-w64-mingw32/lib/libKERNEL32.a

So with that working I started to look at how to work out how I could get windows-rs to work without symlinking the libraries.
I've tried to modify a local copy of windows-rs by swapping the case in the linking macros with promising results but I'm still lacking one library (I think its USER32, I don't have access to my home computer right now). Can't really figure out where I can lower-case the library name.

[kennykerr]

Related to rust-lang/rust#58713 and @ricobbe's work.

[kennykerr]

On my Windows SDK version 10.0.22000.0 installation it is cased as User32.Lib but again the Windows file system is not case-sensitive so I don't know that this is something you can rely on. If you want to experiment with this, you could try to lower-case the following:

windows-rs/crates/gen/src/function.rs

Line 15 in 21ed8f2

let mut link = def.impl_map().expect("Function").scope().name();

[ke1satsu]

Thank you for your help! That line was indeed the one that I needed to change to get it to work:
let mut link = def.impl_map().expect("Function").scope().name().to_lowercase();

This meant that line 21 had to change to:
link = "onecoreuap".to_string();

Together with lower casing the link macros in bindings.rs cross-compilation works in my particular project!

I might have broken two legacy test cases in pwstr.rs however.

[kennykerr]

@abbec @ke1satsu I applied the lowercase change in #1128 - let me know if there is anything else preventing you from cross compiling.

Also feel free to suggest some sort of test that I can add to the build here to make sure cross-compilation keeps working - I don't have any experience with Linux otherwise I would add something.

[ke1satsu]

Awesome! Thanks alot :)

As for tests in the build, I'm sorry to say I've never touched CI/CD so I'm unsure how one could go about checking that in the pipeline. If I figure something out I'll make sure to drop some suggestions here!

[riverar]

I can wire up x86_64-pc-windows-gnu for CI later tonight 👍

[kennykerr]

Thanks!

[riverar]

@ke1satsu What are you using to satisfy onecoreuap dependencies? It doesn't appear mingw ships this umbrella lib. I'm guessing you didn't try the crate tests and you're carefully using APIs that don't need this in your project.

[ke1satsu]

Your guess was spot on, I just needed a limited few API calls for what I tried to do. I saw that some tests broke but I wasn't sure what the tests really did so I left them alone.

You also seem right in that mingw doesn't seem to include onecoreuap, unless its bundled somewhere. I tried googling it and there are surprisingly few threads complaining about it lacking so I'm not really sure.

[riverar]

@ke1satsu Hah, thanks for the quick follow up! I'll think some more about how we handle this.

[mati865]

It's true that most (all?) umbrella libraries are missing from mingw-w64. Nobody asked for it on the mailing list yet so I think they would accept patches adding it.