Rust: Use msvc on windows, not mingw

[graydon]

We're using a pretty rare toolchain on windows. Msvc is the "standard" one, and it'd be good if we could ship a rustc that is comfortable with the native windows toolchain rather than mingw.

[kyonifer]

This issue is very relevant if rust eventually allows linking with C code (i.e. issue #1850). Although in theory the MinGW C toolchain is ABI compatible with MSVC, in practice this isn't the case and will cause things to fail in subtle and mysterious ways, especially as code size gets large. Sorry for the long list of examples that follows, but I wanted to illustrate the issues I've had with MinGW/MSVC interop.

• MinGW and MSVC actually use different symbol decorations for similar usages of stdcall/dllimport, requiring modification of headers (or passing extra flags to the compiler) to even begin to link.
• Linking a static .lib built with MSVC to object files generated by MinGW with ld.exe will rarely work, even according to their own documentation. My personal experience is that usually ld.exe will segfault when attempting anything more than a trivial example. Having rustc use link.exe (MSVC) on Windows would be a huge step towards interop with existing VC++ code.
• The situation with DLLs is better, but still a mess. Import libraries rarely "just work", and you'll end up having to extract/write .def files or link to the .dll directly; after spending an hour messing with things like reimp.exe and the --out-implib flag, you'll start to wonder why you are using MinGW in the first place, and if you could avoid it somehow.
• Even if you manage to get the DLL to link, MinGW dlls link against msvcrt.dll and VC++10 links against msvcr100.dll, causing subtle bugs when data is passed cross DLL boundary and used with different runtimes. This limitation plagues a lot of Linux software compiled on Windows via MinGW. Examples include GTK+ which requires one to use the outdated VC++6 compiler or MinGW to compile code linking against it, and Qt has separate distributions for MinGW and the various MSVC versions.

Certainly this last issue applies to any code compiled with incompatible version of a compiler (i.e. VS2005/VS2010), however the issue is that mingw links with such an outdated version of MSVC that it is not useful for new code being compiled today. I've seen activity in the MinGW mailing list about working with msvcr100.dll, so this may disappear soon. However, it still stands that using static/shared libs built with the MS toolchain with MinGWs toolchain is somewhere between a lot of hassle and impossible. This hassle would be saved if compiling .c code (e.g. #1850) was done with MSVC, and then linked with the rustc objects generated by llvm.

Note that I have very little experience with llvm, so i'm not sure how compatible LLVM's ABI (used for rust objects) is with MSVC. I know that it is possible to be compatible though, as Intel's compiler (icc) does just fine importing .lib/.def/.dll's built with MSVC. If llvm is anywhere near as compatible as icc with with cl.exe/link.exe then rustc would inherit those advantages.

[fithisux]

I would like to comment on the random assumption that mingw is "a pretty rare toolchain on windows".

Facts :
equation.com maintains a mingw toolchain for scilab
mingw-w64 makes adjustments and improvements
google go can be compiled with mingw
ReactOS uses a mingw environment
numerous FOSS projects embrace mingw

prove that the comment is invalid. For my work mingw is vital while rust is not. However mingw gives me an opportunity to explore rust and consider it for future products. The fact that Mozilla embraces Visual Studio does not prove that VS is necessarily the only option. Chromium is a counterexample. The lack of interoperability of mingw with VS is also something that I do not _personally_ consider a big issue.

Mingw is interoperable with many scripting languages, many full fledged languages like FreePascal/Mono/D and Go. In this respect I would like to ask you to maintain mingw along with VS or keep mingw and add clang+mingw libs.

[Blei]

Problem: jemalloc requires mingw.

[jdm]

Firefox uses jemalloc on Windows with MSVC: http://glandium.org/blog/?p=2581

[thestinger]

jemalloc definitely supports MSVC, but I don't think it supports acting as a drop-in malloc/free replacement for the entire process. I think you have to compile it with the je_ prefix and switch the calls to that, so we would lose LLVM's hardcoded optimizations for malloc/free but not much else.

[Aatch]

@thestinger it's actually not as hard coded as it seems. There's just a list of library calls and some information about them as a function pass. We should be able to extend it to provide the appropriate data to let LLVM do the optimizations for je_ prefixed versions same as the regular calls.

[thestinger]

@Aatch: there's more than just that - there are specific optimizations related to free and malloc

http://llvm.org/docs/doxygen/html/InstructionCombining_8cpp_source.html#l01378
http://llvm.org/docs/doxygen/html/Local_8cpp_source.html#l00269

[pnkfelix]

visiting for bug triage, email from 2013-08-05

[klutzy]

We use some c99 functions like fdim but it is not in msvcrt runtime. #8663 indicates that mingw/mingw-w64 implement them manually, so for msvc we have to import some portion from them.

[thestinger]

9367 is a better solution, since we're strongly tied to LLVM and we can distribute the toolchain with our snapshots + installer. They are striving to be fully compatible with the existing MSVC++ toolchain.