MinGW、MinGW-w64 與TDM-GCC 應該如何選擇？

01-15

我推薦用MinGW-w64。支持x64，winapi支持更全面，奇怪的毛病少。但需要在thread library和異常模型上做出選擇。

MinGW的winapi是有些問題的。比如很久以前我寫的一個帖子在MinGW下使用DShow的方法DShow的頭文件vmr9.h里甚至有語法錯誤，MixerPref9_RenderTargetMask = 0x000FF000後面沒有逗號。

TDM-GCC也用過很短的一段時間，不過沒有跟別的比較過。

MinGW已經不推薦使用。只有32位版，更新速度也不怎麼樣。

MinGW-w64更新最快，基本上gcc更近後幾周內就會跟進。32位和64位都提供。

TDM-GCC，更新速度也不怎麼樣，同時提供32位和64位。

涉及64位時，TDM-GCC和MinGW-w64還有一個重要的區別，64位的TDM-GCC既能編譯64位binary，也能編譯32位binary（用-m32參數）。而MinGW-w64無此能力，你需要裝32位和64位的兩套MinGW w64 tool chain來編譯兩種binary。

2016-04-18

找到一些帖子：

MinGW MinGW-w64 TDM-GCC等工具鏈之間的區別與聯繫

MinGW-w64 Vs TDM-GCC Vs e.g . MinGW Distro

2016-09-13

Windows C++ compiler with full C++11 support (should work with Qt)

----

MinGW是最早的一個，

mingw-w64最初是某公司內部因為MinGW的不足而自己搞的，後來開源，支持原生64位Windows，現在的地位基本取代了原來的MinGW

TDM-GCC是http://tdragon.net搞的用於MinGW和mingw-w64的gcc分支，使用廣泛

幾個打了Windows補丁的GCC編譯器。

推薦使用tdm-gcc，基於最新版本的GCC。

mingw很久才會更新一次。

TDM-GCC : Quirks

What distinguishes TDM-GCC from other GCC distributions?

TDM-GCC : About

tdmgcc，mingw是一個編譯器，附帶自己的運行庫來實現CLib。

cygwin是一個POSIX兼容層+一堆移植的程序，在Windows上模擬Linux的API，類似於WINE。

msys 是mingw加上一些工具讓你能夠執行make命令。比如cp，awk之類的。

msys2 = mingw-w64 + pacman 。工具部分用cygwin移植。

我用了MinGW一段時間了,如果你要開發windows平台應用,最好還是用CL不然有很多麻煩.問題也有很多.

首先它的鏈接器不如MS,若全靜態鏈接即使一個Hello World都要4,5M.當然若你不用標準庫的話可以更小.不過話又說回來,有幾個人能完全自己實現標準庫啊.

第三方的Com庫TLB這些要自己導入.即使是Windows平台下那些庫,MinGW有些封裝的庫是有問題的.

資源文件要自己寫.

而且GCC雖然更得快,有很多莫名其妙的問題,而且最近版本號更得快,問題就更多了.

比如說constexpr不能用於指針,在4.8版本是可以的,到了4.9版本就不可以了.然後我現在用5.3又可以了,最新版又不可以了.因為按照C++標準,就是不可以.我過去某個手法是可以的,到了最新版又不可以了.可以看出GCC處在一個調整期,要相當長一段時間才能穩定下來.

GCC本身就有些眾所周知的問題,如static const必須外部初始化,或者開到O2.一直它都沒解決,好像它也沒打算解決.按照XP的思想,代碼中不能有重複的部分.

當然MinGW也是有好處的,一是支持XP,它不會像MS那樣刻意在自己最新版開發工具中限制你只能鏈接到高於某個版本的操作系統.另一方,它追標準快,現在它已經實現C++17的Fold expression,其實也沒什麼大用,總能少打兩個字.但可以看出比起其它編譯器,它算最積極的.

=============================2017-10-20最新修改=======================

時光飛逝,歲月如梭,GCC和MinGW也不會原地踏步,現在MinGW的體積要小很多了,以《Programming Windows 5》的HelloMsg為例,HelloMsg.exe,Delphi 5 14K,VC6 24K,MinGW7(Os+flto+strip)17K,就體積而論,雖然比Delphi18年前的水平還差一點,但是已經可以實用了.

以上說的肯定都是靜態編譯,有些人,他那動態鏈接去跟靜態的比,最後還來懷疑我是不是靜態編譯.

再加上cygwin，msys和msys2吧

以前一直用cygwin，現在sublime text以及notepad++都調用的是TDM-GCC

和題主問題相關的伴生選擇有：msys、msys2、msys-git，推薦

http://msys2.github.io

因為，參考msys2的作者在stackoverflow上的說明：

How are msys, msys2, and msysgit related to each other?

While MSYS isn"t dead, I would say it"s not looking very healthy either. It is a project started by the mingw team many years ago as a fork of Cygwin that never kept up with Cygwin.
msysgit is a fork of a slightly older version of MSYS with some custom patches, old versions of bash and perl and a native port of git.
MSYS2 is a project started by Alexey Pavlov of the mingw-builds team (who are the official packagers for MinGW-w64 toolchains) as a recent fork of Cygwin which tracks the latest Cygwin closely so that it doesn"t end up out of date. Alexey forward ported the old MSYS patches and added some of his own.
As well as providing the necessary Unix tools with which to compile native software - the stated goal of MSYS - we ported the Pacman package manager from Arch Linux. Pacman is more than just about managing binary packages (though it does that very well). It has a software building infrastructure called makepkg that allows the creation of recipes (PKGBUILD and patch files) for building software. IMHO the adoption of Pacman changes things significantly for Open Source development on Windows. Instead of everyone hacking on their own bespoke shell scripts to build software in a hodge-podge, incompatible way, packages can now depend on other packages and PKGBUILD files and associated patches can be used as a reference for constructing new PKGBUILDs. It"s as close to a Linux system as a (native) Windows can get (Arch in particular) and allows for simple updating of all the installed packages.