Эта проблема очень актуальна, если ржавчина в конечном итоге позволяет связываться с кодом C (например, проблема № 1850). Хотя теоретически инструментальная цепочка MinGW C является ABI-совместимой с MSVC, на практике это не так и приведет к сбою тонкими и загадочными способами, особенно по мере увеличения размера кода. Извините за длинный список следующих примеров, но я хотел проиллюстрировать проблемы, которые у меня были с взаимодействием MinGW / MSVC.

• MinGW и MSVC фактически используют разные украшения символов для аналогичного использования stdcall / dllimport, требуя изменения заголовков (или передачи дополнительных флагов компилятору), чтобы даже начать связывание.
• Связывание статического .lib, созданного с помощью MSVC, с объектными файлами, созданными MinGW с помощью ld.exe, редко будет работать, даже в соответствии с их собственной документацией. По моему личному опыту, ld.exe обычно вызывает ошибку при попытке выполнить что-либо, кроме тривиального примера. Использование Rustc link.exe (MSVC) в Windows было бы огромным шагом на пути к взаимодействию с существующим кодом VC ++.
• С DLL лучше, но все равно бардак. Библиотеки импорта редко «просто работают», и вам придется извлекать / записывать файлы .def или напрямую связываться с .dll; потратив час на возню с такими вещами, как reimp.exe и флаг --out-implib, вы начнете задаваться вопросом, почему вы вообще используете MinGW, и можно ли как-то избежать этого.
• Даже если вам удастся связать DLL, библиотеки DLL MinGW связываются с msvcrt.dll и VC ++ 10 связываются с msvcr100.dll, вызывая тонкие ошибки, когда данные передаются через границу DLL и используются с разным временем выполнения. Это ограничение характерно для многих программ Linux, скомпилированных для Windows через MinGW. Примеры включают GTK +, который требует использования устаревшего компилятора VC ++ 6 или MinGW для компиляции кода, связывающегося с ним, и Qt имеет отдельные дистрибутивы для MinGW и различных версий MSVC.

Конечно, эта последняя проблема относится к любому коду, скомпилированному с несовместимой версией компилятора (например, VS2005 / VS2010), однако проблема в том, что mingw связывается с такой устаревшей версией MSVC, что она бесполезна для нового кода, компилируемого сегодня. Я видел активность в списке рассылки MinGW по поводу работы с msvcr100.dll, так что это может скоро исчезнуть. Тем не менее, по-прежнему считается, что использование статических / общих библиотек, созданных с помощью инструментальной цепочки MS с инструментальной цепочкой MinGWs, где-то между множеством хлопот и невозможностью. Эта проблема была бы устранена, если бы компиляция кода .c (например, # 1850) была выполнена с помощью MSVC, а затем была связана с объектами rustc, созданными с помощью llvm.

Обратите внимание, что у меня очень мало опыта работы с llvm, поэтому я не уверен, насколько ABI LLVM (используемый для объектов ржавчины) совместим с MSVC. Я знаю, что совместимость возможна, поскольку компилятор Intel (icc) отлично импортирует .lib / .def / .dll, созданные с помощью MSVC. Если llvm настолько же совместим, как icc, с cl.exe / link.exe, тогда rustc унаследует эти преимущества.

Я хотел бы прокомментировать случайное предположение, что mingw - это «довольно редкая цепочка инструментов для Windows».

Факты:
Equation.com поддерживает набор инструментов mingw для Scilab
mingw-w64 вносит изменения и улучшения
google go можно скомпилировать с mingw
ReactOS использует среду mingw
многочисленные проекты FOSS охватывают mingw

доказать, что комментарий недействителен. В моей работе Mingw жизненно необходим, а ржавчина - нет. Однако mingw дает мне возможность изучить ржавчину и рассмотреть ее для будущих продуктов. Тот факт, что Mozilla использует Visual Studio, не доказывает, что VS обязательно является единственным вариантом. Хром - контрпример. Отсутствие взаимодействия mingw с VS - это тоже то, что я лично не считаю большой проблемой.

Mingw совместим со многими языками сценариев, многими полноценными языками, такими как FreePascal / Mono / D и Go. В связи с этим я хотел бы попросить вас поддерживать mingw вместе с VS или оставить mingw и добавить библиотеки clang + mingw.

Проблема: jemalloc требует mingw.

Firefox использует jemalloc в Windows с MSVC: http://glandium.org/blog/?p=2581

jemalloc определенно поддерживает MSVC, но я не думаю, что он поддерживает функцию замены malloc / free для всего процесса. Я думаю, вам нужно скомпилировать его с префиксом je_ и переключить вызовы на него, чтобы мы потеряли жестко запрограммированные оптимизации LLVM для malloc / free, но не более того.

@thestinger на самом деле не так жестко запрограммирован, как кажется. Есть просто список вызовов библиотеки и некоторая информация о них в виде прохода функции. Мы должны иметь возможность расширить его, чтобы предоставить соответствующие данные, чтобы позволить LLVM выполнять оптимизацию для версий с префиксом je_ так же, как и для обычных вызовов.

@Aatch : это больше, чем просто это - есть определенные оптимизации, связанные с free и malloc

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

посещение для выявления ошибок, электронное письмо от 5 августа 2013 г.

Мы используем некоторые функции c99, например fdim но их нет в среде выполнения msvcrt. # 8663 указывает, что mingw / mingw-w64 реализуют их вручную, поэтому для msvc мы должны импортировать некоторую часть из них.

9367 - лучшее решение, поскольку мы сильно привязаны к LLVM и можем распространять цепочку инструментов с помощью наших снимков и установщика. Они стремятся быть полностью совместимыми с существующим набором инструментов MSVC ++.