fix building mingw32 rust with default gcc

[hcorion]

Hiya folks. I've been working on updating msys2's rust package. As noted in the appveyor.yml rust i686-pc-windows-gnu doesn't build on the default mingw32 compiler.

For 32-bit the installed gcc toolchain on AppVeyor uses the pthread threading model. This is unfortunately not what we want, and if we compile with it then there's lots of link errors in the standard library (undefined references to pthread symbols).

Why does it compile with the 64-bit mingw64 gcc then? What is so different that it compiles with the 64-bit one but not the 32-bit gcc? If this is not rust's fault, could a bug be filed on the MINGW-Packages repo by someone who knows what the problem is?

[jsen-]

Adding some console output

[alexcrichton]

Why does it compile with the 64-bit mingw64 gcc then?

On 64-bit MinGW we use a different unwinding strategy for panics. That is, we vendor our own implementation which doesn't rely on any MinGW libraries.

On 32-bit MinGW, however, we use the standard MinGW libraries for an unwinding implementation. On the pthreads toolchain these libraries reference pthread symbols, which we don't link by default. On the win32 toolchain these libraries link the win32 symbols, which we do indeed link by default.

Does that make sense?

[alexcrichton]

Er and to expand on that, because on 64-bit MinGW we don't use any standard libraries, it doesn't matter what toolchain you're using as we're compatible with both.

[jsen-]

Does anyone have steps to overcome this?
I've used the same version of mingw-w64 that msys provides, just compiled with win32 thread support instead of posix.
Unfortunately then cmake was not able to detect gcc version...
I was shuffling stuff around until I made it work.
Now I have a working environment for i686-pc-windows-gnu, but I'm not able to reproduce it.

[alexcrichton]

The immediate fix, write our own unwinder, is unfortunately very unlikely to work any time in the near future. Apart from that a possible solution could try to be dynamic detection of what toolchain we're working with to link the right libraries, perhaps.

[hcorion]

@jsen- I was able to get it to build by doing:
make RUSTFLAGS="$RUSTFLAGS -C link-args='-lffi -lpthread'"
this makes it build i686 rust, but the same commands don't seem to work with building cargo, which fails every single time.

[hcorion]

I've almost got the mingw PKGBUILD to a working state, it is just that gosh darn cargo build that won't take any of my flags.

[mati865]

make RUSTFLAGS="$RUSTFLAGS -C link-args='-lffi -lpthread'"
Allows to build i686 rust but to build any .rs file you have to call rustc -C link-args='-lpthread' every time.

@alexcrichton I'm just starting to understand how rust build system works but I think it would be possible to add target triples i686-w64-mingw32 and x86_64-w64-mingw32. Which would in turn link to libs provided by MSYS2.
I've been trying adding -lpthread and -pthread in several places but it didn't work. Could you point me where should I add it to work properly as temporary workaround?

EDIT: Instead of creating additional target cmake option could be added to force pthread linking with mingw.

[alexcrichton]

Unfortunately this is likely to be an uphill battle. There's no easy workaround AFAIK to get this working, and you'd basically be blazing a new trail. It's unlikely we'll add new targets for this use case as well, but not implausible!

[mati865]

I understand adding additional target could be overkill. Is there developer that I could contact by mail or IRC about rust build system?

EDIT: Never mind, I think I've found it.
EDIT2: Now 32 bit Rust is fine, 64 is building to test it. Should I open feature request (for additional configure options) or create PR with changes?

[alexcrichton]

Ah I'm likely the developer you'd want to contact about the build system! You can find me as acrichto on IRC. But yeah if you've got a patch feel free to send a PR!

[Mark-Simulacrum]

Now 32 bit Rust is fine, 64 is building to test it.

This edit by @mati865 seems to suggest that this has been fixed, so perhaps we can close? @mati865 could you confirm that you've managed to fix this or let us know if it's still broken (I assume it is, I think, since I don't recall us doing anything to fix it).

[mati865]

Issue is resolved and should be closed.