Unable to cross-compile from Linux to Windows using mingw-w64

[melvyn2]

cargo run --target x86_64-pc-windows-gnu --bin graph gave the following errors:
https://gist.github.com/melvyn2/6c34ef3f82ecddca072fb8202c77bff8#file-build-log

It's a whole lot of undefined reference to errors to c++ standard symbols, like __gxx_personality_seh0 and __cxa_rethrow, along with Qt symbols like QtSharedPointer::ExternalRefCountData::operator delete(void*). Searching around, this seems to be caused by not linking in libstc++, but checking the linker call it's being included. I'm able to cross-compile and run other rust projects with my current setup, so I'm not sure what's breaking here exactly.

[melvyn2]

Adding the mingw-w64 bin directory to the liker search directory (with println!("cargo:rustc-link-search=/usr/x86_64-w64-mingw32/lib/")) worked as a workaround, but that makes this look like an upstream bug in the cc crate. I'll file an issue there instead.

[melvyn2]

This is actually caused by me not setting QMAKE=x86_64-w64-mingw32-qmake-qt5, so the qmake detection uses the system/host qmake instead, which doesn't return the right paths. Maybe detection could be improved so that the target qmake is picked up instead? I'll see if I can make a PR for this.

[ogoffart]

Thanks for your investigations. I don't have that setup so i can't try this platform.
It would be nice if this could work out of the box.
But the "target qmake" is actually very platform dependend and cannot really be hardcoded. How could we determine the "target qmake"?

[melvyn2]

The cc crate determines the target compiler name from a hardcoded map from target name -> compiler prefix. It might be possible to reuse their code by calling get_compiler and replacing the compiler with qmake, but this looks pretty fragile. I'll see if there's any more reliable way.
An intermediate solution could be to reject or at least warn when QMAKE_XSPEC doesn't match cargo's given target.