이 문제는 Rust가 결국 C 코드와의 연결을 허용하는 경우(즉, 문제 #1850) 매우 관련이 있습니다. 이론적으로 MinGW C 도구 체인은 MSVC와 ABI 호환 가능하지만 실제로는 그렇지 않으며 특히 코드 크기가 커질수록 미묘하고 신비한 방식으로 실패하게 됩니다. 다음에 나오는 예제의 긴 목록에 대해 유감스럽게 생각하지만 MinGW/MSVC interop에서 겪었던 문제를 설명하고 싶었습니다.

• MinGW와 MSVC는 실제로 stdcall/dllimport의 유사한 사용법에 대해 서로 다른 기호 장식을 사용하므로 링크를 시작하려면 헤더 수정(또는 컴파일러에 추가 플래그 전달)이 필요합니다.
• MSVC로 빌드된 정적 .lib를 ld.exe를 사용하여 MinGW에서 생성된 개체 파일에 연결하는 것은 자체 설명서에 따르면 거의 작동하지 않습니다. 내 개인적인 경험은 일반적으로 ld.exe가 사소한 예제 이상을 시도할 때 segfault가 발생한다는 것입니다. Rustc가 Windows에서 link.exe(MSVC)를 사용하는 것은 기존 VC++ 코드와의 상호 운용성을 향한 큰 단계가 될 것입니다.
• DLL의 상황은 더 나아졌지만 여전히 엉망입니다. 가져오기 라이브러리는 "그냥 작동"하는 경우가 거의 없으며 결국 .def 파일을 추출/작성하거나 .dll에 직접 연결해야 합니다. reimp.exe 및 --out-implib 플래그와 같은 것들을 어지럽히는 데 한 시간을 보낸 후에는 처음에 MinGW를 사용하는 이유와 어떻게든 피할 수 있는지 궁금해하기 시작할 것입니다.
• DLL을 링크하도록 관리하더라도 MinGW dll은 msvcrt.dll에 대해 링크하고 VC++10은 msvcr100.dll에 대해 링크하므로 데이터가 DLL 경계를 넘어 전달되고 다른 런타임과 함께 사용될 때 미묘한 버그가 발생합니다. 이 제한은 MinGW를 통해 Windows에서 컴파일된 많은 Linux 소프트웨어를 괴롭힙니다. 예에는 구식 VC++6 컴파일러 또는 MinGW를 사용하여 이에 대한 코드를 컴파일해야 하는 GTK+가 포함되며 Qt에는 MinGW 및 다양한 MSVC 버전에 대한 별도의 배포판이 있습니다.

확실히 이 마지막 문제는 호환되지 않는 컴파일러 버전(예: VS2005/VS2010)으로 컴파일된 모든 코드에 적용되지만 문제는 mingw가 MSVC의 오래된 버전과 연결되어 오늘날 컴파일되는 새 코드에는 유용하지 않다는 것입니다. MinGW 메일링 리스트에서 msvcr100.dll 작업에 대한 활동을 보았으므로 곧 사라질 수 있습니다. 그러나 여전히 MinGWs 도구 체인과 함께 MS 도구 체인으로 구축된 정적/공유 라이브러리를 사용하는 것은 많은 번거로움과 불가능 사이의 어딘가에 있습니다. .c 코드(예: #1850)를 MSVC로 컴파일한 다음 llvm에 의해 생성된 rustc 개체와 연결하면 이러한 번거로움이 줄어들 것입니다.

llvm에 대한 경험이 거의 없으므로 LLVM의 ABI(녹 개체에 사용됨)가 MSVC와 얼마나 호환되는지 잘 모르겠습니다. Intel의 컴파일러(icc)가 MSVC로 빌드된 .lib/.def/.dll을 잘 가져오기 때문에 호환이 가능하다는 것을 알고 있습니다. llvm이 cl.exe/link.exe와 함께 icc만큼 호환되는 경우 Rustc는 이러한 이점을 상속합니다.

나는 mingw가 "윈도우에서 매우 드문 도구 체인"이라는 무작위 가정에 대해 언급하고 싶습니다.

사실:
equation.com은 scilab용 mingw 도구 체인을 유지 관리합니다.
mingw-w64는 조정 및 개선
Google go는 mingw로 컴파일할 수 있습니다.
ReactOS는 mingw 환경을 사용합니다.
수많은 FOSS 프로젝트가 mingw를 수용합니다.

주석이 무효임을 증명합니다. 내 작업을 위해 mingw는 중요하지만 녹은 그렇지 않습니다. 그러나 mingw는 녹을 탐색하고 향후 제품에 대해 고려할 기회를 제공합니다. Mozilla가 Visual Studio를 수용한다는 사실이 VS가 반드시 유일한 옵션임을 증명하지는 않습니다. 크롬은 반례입니다. mingw와 VS의 상호 운용성 부족도 _개인적으로_ 큰 문제로 생각하지 않는 것입니다.

Mingw는 많은 스크립팅 언어, FreePascal/Mono/D 및 Go와 같은 많은 완전한 언어와 상호 운용 가능합니다. 이와 관련하여 VS와 함께 mingw를 유지하거나 mingw를 유지하고 clang+mingw 라이브러리를 추가해 달라고 요청하고 싶습니다.

문제: jemalloc에는 mingw가 필요합니다.

Firefox는 MSVC가 있는 Windows에서 jemalloc을 사용합니다. http://glandium.org/blog/?p=2581

jemalloc은 확실히 MSVC를 지원하지만 전체 프로세스에 대한 drop-in malloc/free 교체 역할을 지원하지 않는다고 생각합니다. je_ 접두사로 컴파일하고 호출을 전환해야 한다고 생각합니다. 그러면 malloc/free에 대한 LLVM의 하드코딩된 최적화가 손실되지만 그 외에는 많지 않습니다.

@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

버그 분류를 위해 방문, 2013-08-05의 이메일

fdim 와 같은 일부 c99 함수를 사용하지만 msvcrt 런타임에는 없습니다. #8663은 mingw/mingw-w64가 수동으로 구현함을 나타내므로 msvc의 경우 일부를 가져와야 합니다.

9367은 LLVM에 강력하게 연결되어 있고 스냅샷 + 설치 프로그램으로 도구 체인을 배포할 수 있기 때문에 더 나은 솔루션입니다. 그들은 기존 MSVC++ 도구 체인과 완벽하게 호환되도록 노력하고 있습니다.