Bundled gcc/libraries on windows may cause errors when compiling native code

[alexcrichton]

I have just run into a problem when building Cargo that looks like as follows:

• Cargo relies on a number of libraries from the MinGW installation, so when it downloads a Rust snapshot compiler we delete the gcc.exe in the distribution.
• On Windows, we build libcurl from source using a checked in configure script. This configure script runs against the system gcc.
• The libcurl configure script detects that strtok_r is available on the local system in the libmingwex.a library in the /mingw64/x86_64-w64-mingw32/lib directory. The configure script detects this by running the system gcc against a test file.
• When Cargo itself is linked together it uses the system gcc again, but this time it has a -L flag to the directory where all the Rust bundled gcc libraries are.
• It turns out that Rust ships a libmingwex.a, and this used instead of the /mingw64 one. It also turns out that this libmingwex.a that we ship does not contain strtok_r.
• The linking step for Cargo fails because libcurl expected to find strtok_r in libmingwex.a, but the wrong libmingwex.a was linked in so the symbol was ultimately undefined.

I think we may want an installation option for Rust which opts out of installing the bundled gcc compiler (but we still do it by default) to solve this. cc @vadimcn, @brson.

[brson]

:tableflip:

[retep998]

And this is why I still refuse to use the nightly builds of Rust on Windows.

[vadimcn]

@alexcrichton: Is the cargo bot using mingw-w64 toolchain? If not, is it possible to sync it with Rust's?
Otherwise, I suppose you could just delete libmingwex.a as well.

It should be possible to split gcc into a separate installable component. I'll look into that.

[alexcrichton]

The cargo bot is using mingw-w64, I'm not quite sure how it was installed (@brson would know). While possible to sync with Rust's, this is a general problem that we still need to address I believe. I discovered this, for example, on my own VM which is out of sync with Rust's toolchain. For now yeah I'm just deleting libmingwex.a.

I definitely still think we should install gcc by default, but having an option to opt-out would perhaps be nice (not a high priority at all). I just wanted to write this up to track the issue.

[klutzy]

I've heard that on gcc-less scenario users must install own mingw-w64 with the version nightly uses.
Frankly I don't know what's the actual issues about the version mismatch. (I'm just guessing that if target dylib contains crt0/libgcc/... different to what exe does then it can be problematic in some way)
@vadimcn Could you elaborate more on that?

[alexcrichton]

In the case that I discovered, the version mismatch was a problem because of:

• The Rust bundled gcc libs did not define strtok_r
• My own system's gcc libs defined strtok_r
• The configure script of curl was using the system gcc instead of the bundled gcc, and it detected that the system had strtok_r present.
• When linking, the bundled gcc libs were used instead of the system libs, and strtok_r was not provided.

I don't think that there was an actual incompatibility between the libraries other than just not having the same set of symbols.

[vadimcn]

@klutzy:

• If the external Mingw was compiled with SjLj exceptions, linking Rust objs with it will be missing several EH-related symbols, because SjLj names for those are different.
• Not so long ago GCC underwent an ABI change (related to passing of int64 arguments, I think). So if you link with pre-4.7 GCC libraries, stuff is likely to break.

I am sure there's more...

[vadimcn]

@alexcrichton: Windows installer does allow opting-out of bundled gcc. I think this can be closed.

[alexcrichton]

Perfect, thanks @vadimcn!

[kryptan]

Today I've hit the issue with strtok_r being used by libcurl. I've built my libcurl using mingw-w64 v4.0.6. I don't know how to opt-out of installing mingw libs using rustup. I fixed it by replacing bundled libmingwex.a with the one from mingw-w64 v4.0.6.
Why bundled mingwex doesn't contain strtok_r? Is it outdated?

EDIT: Looks like opting out of mingw installation is not yet implemented in rustup: rust-lang/rustup#298