windows - Cygwin和MinGW有什麼區別?(MinGW從Cygwin 1.3.3版本中分離出來)

windows - Cygwin和MinGW有什麼區別?

我想讓個人C ++項目跨平臺,我正在考慮使用Cygwin / MinGW。 可是他們之間有什麼區別呢?html

另外一個問題是,若是沒有Cygwin / MinGW,我可否在系統上運行二進制文件?node

 Answers


Cygwin是嘗試在Windows上建立一個完整的UNIX / POSIX環境。 要作到這一點,它使用各類DLL。 雖然這些DLL被GPLv3 +覆蓋,可是它們的許可證包含一個異常 ,不會強制派生的工做被GPLv3 +覆蓋。 MinGW是一個C / C ++編譯器套件,它容許您建立Windows可執行文件而不依賴於這樣的DLL - 您只須要普通的MSVC運行時,這是Microsoft Windows正常安裝的一部分。mysql

你也能夠獲得一個小的UNIX / POSIX環境,用MinGW編譯成MSYS 。 它沒有Cygwin的全部功能,但對於想要使用MinGW的程序員來講是很是理想的。ios

做爲一個簡化,就是這樣的:git

  • 在Cygwin中編譯一些東西,而後編譯Cygwin 。程序員

  • 編譯MinGW中的東西,你正在爲Windows編譯它。github

關於Cygwinsql

Cygwin的目的是經過模擬許多基於Unix的操做系統提供的小細節,並經過POSIX標準來記錄,使得基於nix的應用程序更容易移植到Windows上。 若是您的應用程序假定它可使用Unix功能,例如管道,Unix風格的文件和目錄訪問等等,那麼您能夠在Cygwin中編譯它,而Cygwin自己將做爲您的應用程序的兼容層 ,這些特定於Unix的範例能夠繼續使用,對應用程序進行不多或不須要修改。編程

若是你想爲Cygwin編譯一些東西並分發這個應用程序,那麼你還必須將Cygwin運行時環境(由cygwin1.dll提供)與它一塊兒cygwin1.dll , 這對你可能使用哪一種類型的軟件許可有影響 。windows

關於MinGW

MinGW是GNU編譯器工具的Windows端口,例如GCC,Make,Bash等等。 它不會試圖模擬或提供與Unix的全面兼容性,而是提供在Windows上使用GCC(GNU編譯器)和少許其餘工具的最低必要環境。 它沒有像Cygwin同樣的Unix仿真層,可是結果是你的應用程序須要特別的編程才能在Windows上運行,這可能意味着若是它被建立爲依賴於在標準Unix環境中運行,使用Unix特有的功能,好比前面提到的功能。 默認狀況下,在MinGW的GCC中編譯的代碼將編譯爲本機Windows X86目標,包括.exe和.dll文件,可是也可使用正確的設置進行交叉編譯。 MinGW是Microsoft Visual C ++編譯器及其關聯的連接/製做工具的開源替代品。

存在至關複雜的跨平臺框架,這使得將應用輕鬆移植到各類操做系統的任務成爲可能 - 例如Qt框架是跨平臺應用的流行框架。 若是您從一開始就使用這樣的框架,那麼您不只能夠減小在移植到其餘平臺時遇到的麻煩,並且能夠在全部平臺上使用相同的圖形窗口小部件(窗口,菜單和控件) GUI應用程序。

要添加到其餘答案,Cygwin附帶MinGW庫和標題,您能夠經過使用-mno-cygwin標誌與gcc編譯而不連接到cygwin1.dll。 我很是喜歡使用簡單的MinGW和MSYS。

維基百科在這裏作一個比較。

從Cygwin的網站 :

  • Cygwin是一個相似於Linux的Linux環境。 它由兩部分組成:一個DLL(cygwin1.dll),充當Linux API仿真層,提供大量的Linux API功能。
  • 提供Linux外觀的一系列工具。

從Mingw的網站 :

MinGW(簡稱「GNU for Windows」)是一個可免費得到並可自由分發的Windows特定頭文件和導入庫的集合,與GNU工具集相結合,能夠生成不依賴任何第三方C運行時DLL的本地Windows程序

Cygwin使用DLL,cygwin.dll(或者一組DLL)在Windows上提供相似於POSIX的運行時。

MinGW編譯爲本機Win32應用程序。

若是你用Cygwin構建一些東西,你安裝它的任何系統也將須要Cygwin DLL。 MinGW應用程序不須要任何特殊的運行時。

閱讀這些回答的問題,瞭解Cygwin和MinGW之間的區別。

問題1:我想建立一個我編寫源代碼的應用程序,編譯一次並在任何平臺(例如Windows,Linux和Mac OS X ...)中運行它。

解答#1:用JAVA寫你的源代碼。 編譯一次源代碼並在任何地方運行。

問題2:我想建立一個我編寫源代碼的應用程序,但沒有任何問題,我能夠分別編譯任何平臺的源代碼(例如Windows,Linux和Mac OS X ...)。

答案2:用C或C ++寫你的源代碼。 只使用標準頭文件。 爲任何平臺使用合適的編譯器(例如Windows的Visual Studio,Linux的GCC和Mac的XCode)。 請注意,您不該該使用任何高級編程功能在全部平臺上成功編譯您的源代碼。 若是您不使用C或C ++標準類或函數,則您的源代碼不能在其餘平臺中編譯。

問題#3:在問題#2的回答中,每一個平臺都難以使用不一樣的編譯器,有沒有跨平臺的編譯器?

答案3:是的,使用GCC編譯器。 這是一個跨平臺的編譯器。 要在Windows中編譯源代碼,請使用爲Windows提供GCC編譯器的MinGW ,並將源代碼編譯爲本機Windows程序。 不要使用任何高級編程功能(如Windows API)在全部平臺上成功編譯源代碼。 若是您使用Windows API函數,則您的源代碼不會在其餘平臺中編譯。

問題4:C或C ++標準頭文件不提供任何高級編程功能,如多線程。 我能作什麼?

答案4:您應該使用POSIX(便攜式操做系統接口[用於UNIX])標準。 它提供了許多高級編程功能和工具。 許多操做系統徹底或部分POSIX兼容(如Mac OS X,Solaris,BSD / OS和...)。 一些操做系統,雖然沒有正式認證爲POSIX兼容,很大程度上符合(如Linux,FreeBSD,OpenSolaris和...)。 Cygwin爲Microsoft Windows提供了一個基本符合POSIX標準的開發和運行環境。

從而:

要在Windows中使用GCC跨平臺編譯器的優點,請使用MinGW。

要利用Windows中的POSIX標準高級編程功能和工具的優點,請使用Cygwin。

維基百科說 :

MinGWCygwin 1.3.3版本中分離出來。 雖然CygwinMinGW均可以用來將UNIX軟件移植到Windows ,但他們有不一樣的方法: Cygwin目標是提供一個完整的POSIX layer ,提供Linux , UNIXBSD變種中存在的幾個系統調用和庫的模擬。 POSIX layer運行在Windows之上,爲了兼容性而犧牲性能。 所以,這種方法須要使用Cygwin編寫的Windows程序運行在必須與程序一塊兒分發的copylefted兼容性庫的頂部,以及程序的source code 。 MinGW旨在經過直接的Windows API calls提供原生的功能和性能。 與Cygwin不一樣, MinGW不須要兼容層DLL ,所以程序不須要與source code一塊兒分發。

因爲MinGW依賴於Windows API calls ,所以沒法提供完整的POSIX API ; 它沒法編譯一些能夠用Cygwin編譯的UNIX applications 。 具體而言,這適用於須要POSIX功能(如fork() , mmap()ioctl()以及指望在POSIX environment運行的應用程序。 使用自己已經移植到MinGWcross-platform library (例如SDL , wxWidgets , QtGTK+編寫的應用程序一般在MinGW編譯將像在Cygwin那樣容易。

MinGWMSYS的組合提供了一個小型自包含的環境,能夠將其加載到可移動媒體上,而無需在註冊表或計算機上的文件中留下條目。 Cygwin Portable提供了相似的功能。 經過提供更多的功能, Cygwin安裝和維護變得更加複雜。

也能夠MinGW-GCC under POSIX systemsMinGW-GCC under POSIX systems cross-compile Windows applications 。 這意味着開發人員不須要使用MSYS進行Windows安裝來編譯在沒有Cygwin狀況下在Windows運行的軟件。

從移植C程序的角度來看,理解這個的一個好方法就是舉個例子:

#include <sys/stat.h>
#include <stdlib.h>

int main(void)
{
   struct stat stbuf;
   stat("c:foo.txt", &stbuf);
   system("command");
   printf("Hello, World\n");
   return 0;
}

若是咱們把stat _stat ,咱們能夠用Microsoft Visual C編譯這個程序。咱們也能夠用MinGW和Cygwin來編譯這個程序。

在Microsoft Visual C下,該程序將連接到MSVC可再發行的運行時庫: mxvcrtnn.dll ,其中nn是某個版本的後綴。 爲了發佈這個程序,咱們將不得不包含該DLL。 該DLL提供了_stat , systemprintf 。

在MinGW下,該程序將連接到msvcrt.dll ,這是一個內部的,未公開的,未版本化的庫,是Windows的一部分,禁止應用程序使用。 該庫本質上是來自MS Visual C的可再發行的運行時庫的一個分支,供Windows自己使用。

在這兩種狀況下,該計劃將有相似的行爲:

  • stat函數將返回很是有限的信息 - 例如,沒有有用的權限或inode編號。
  • 根據與驅動器c:相關聯的當前工做目錄來解析路徑c:file.txt 。
  • system使用cmd.exe /c來運行外部命令。

咱們也能夠編譯Cygwin下的程序。 相似於MS Visual C使用的可再發行的運行時,Cygwin程序將被連接到Cygwin的運行時庫: cygwin1.dll (Cygwin proper)和cyggcc_s-1.dll(GCC運行時支持)。 因爲Cygwin如今在LGPL之下,即便它不是GPL兼容的免費軟件,咱們也能夠用咱們的程序打包,並運行程序。

在Cygwin下,庫函數的行爲將有所不一樣:

  • stat函數具備豐富的功能,在大多數字段中返回有意義的值。
  • 路徑c:file.txt徹底不理解爲包含驅動器號引用,由於c:後面沒有斜槓。 冒號被認爲是名字的一部分,並以某種方式破壞了它。 在Cygwin中沒有針對卷或驅動器的相對路徑的概念,沒有「當前記錄的驅動器」概念,也沒有每一個驅動器當前的工做目錄。
  • system函數嘗試使用/bin/sh -c解釋器。 Cygwin將根據您的可執行文件的位置來解析/路徑,並但願sh.exe程序與您的可執行文件位於sh.exe位置。

Cygwin和MinGW都容許你使用Win32函數。 若是你想調用MessageBoxCreateProcess ,你能夠這樣作。 你也能夠在MinGW和Cygwin下使用gcc -mwindows輕鬆地建立一個不須要控制檯窗口的程序。

Cygwin不是嚴格的POSIX。 除了提供對Windows API的訪問以外,它還提供了一些Microsoft C函數(在msvcrt.dll找到的東西或可從新分發的msvcrtnn.dll運行時)的本身的實現。 一個例子就是spawn*系列的spawn*系列。 這些在Cygwin上使用而不是forkexec是一個好主意,由於它們更好地映射到沒有fork概念的Windows進程建立模型。

從而:

  • Cygwin程序並不比MS Visual C程序「本地化」,理由是須要庫的伴隨。 Windows上的編程語言實現須要提供本身的運行時,甚至是C語言實現。 Windows上沒有「libc」供公衆使用。

  • MinGW不須要第三方DLL的事實其實是一個缺點, 它取決於Visual C運行時的未公開的Windows內部分支。 MinGW這樣作是由於GPL系統庫異常適用於msvcrt.dll ,這意味着可使用MinGW編譯和從新分發GPL編程的程序。

  • 因爲與msvcrt.dll相比,對POSIX的更普遍和更深刻的支持,Cygwin是迄今爲止移植POSIX程序的優越環境。 因爲它如今在LGPL之下,因此它容許具備各類許可的應用程序(開放源代碼或封閉源代碼)被從新分配。 Cygwin甚至包含VT100仿真和termios ,它們與Microsoft控制檯一塊兒使用! 使用tcsetattr設置原始模式並使用VT100代碼來控制光標的POSIX應用程序將在cmd.exe窗口中正常工做。 就最終用戶而言,這是一個本機控制檯應用程序,使Win32調用來控制控制檯。

然而:

  • 做爲一個本地的Windows開發工具,Cygwin有一些怪癖,好比Windows的外部路徑處理,依賴於像/bin/sh類的硬編碼路徑和其餘問題。 這些差別是使Cygwin程序「非本地」的。 若是程序將路徑做爲參數或從對話框輸入,則Windows用戶指望該路徑的工做方式與其餘Windows程序中的路徑相同。 若是不這樣作,那就是個問題。

插件:在LGPL宣佈後不久,我啓動了Cygnal (Cygwin本地應用程序庫)項目,以提供一個旨在解決這些問題的Cygwin DLL的分支。 程序能夠在Cygwin下開發,而後使用Cygnal版本的cygwin1.dll進行部署,而無需從新編譯。 隨着這個庫的改進,它將逐漸消除對MinGW的需求。

當Cygnal解決路徑處理問題時,能夠開發一個單獨的可執行文件做爲Windows應用程序與Cygnal一塊兒使用時,與Cygwin的/usr/bin下安裝Cygwin路徑無縫工做與Windows路徑。 在Cygwin下,可執行文件將透明地處理/cygdrive/c/Users/bob類的路徑。 在Cygnal版本的cygwin1.dll連接的本地部署中,該路徑將沒有任何意義,而它將理解c:foo.txt 。

不要忽視AT&T的U / Win軟件,該軟件能夠幫助您在Windows上編譯Unix應用程序(最新版本 - 2012-08-06;使用Eclipse公共許可證,版本1.0)。

像Cygwin同樣,他們必須跑到一個圖書館。 在他們的狀況下POSIX.DLL 。 AT&T的工做人員是很是棒的工程師(一樣的團隊給你帶來了ksh和dot ),他們的東西值得一試。

Cygwin模擬整個POSIX環境,而MinGW只是編譯的最小工具集(編譯本地Win應用程序)。因此若是你想讓你的項目跨平臺,二者之間的選擇是明顯的,MinGW。

雖然你可能會考慮在Windows上使用VS,在Linux / Unices上使用GCC。 大多數開源項目都是這樣作的(例如Firefox或Python)。

請注意,效用行爲能夠真正在二者之間變化。

例如,Cygwin tar能夠fork - 由於fork()在DLL中被支持,而mingw版本則不能。 嘗試從源代碼編譯mysql時,這是一個問題。

要在商業/專有/非開源應用程序中使用Cygwin,您須要從Red Hat得到「 許可證買斷 」的數萬美圓; 這使標準許可條款以至關大的成本無效。 谷歌「cygwin許可證費用」,看到前幾個結果。

對於mingw,這樣的成本是不會發生的,許可證(PD,BSD,MIT)是很是寬容的。 您至多可能須要爲您的應用程序提供許可證詳細信息,例如使用mingw64-tdm時所需的winpthreads許可證。

編輯感謝Izzy向日葵:商業許可證再也不是可用的或必要的,由於在Cygwin的winsup子目錄中找到的API庫如今正在 LGPL下分發 ,而不是完整的GPL。

Cygwin旨在爲Windows提供一個或多或少完整的POSIX環境,其中包括一套普遍的工具,旨在提供一個完整的類Linux平臺。 相比之下,MinGW和MSYS提供了一個輕量級的,極簡主義的類POSIX層,只有像gccbash這樣的更重要的工具可用。 因爲MinGW更簡約的方法,它不提供Cygwin提供的POSIX API覆蓋的程度,所以不能構建某些能夠在Cygwin上編譯的程序。

根據二者生成的代碼,Cygwin工具鏈依賴動態連接到一個大的運行時庫cygwin1.dll ,而MinGW工具鏈將代碼編譯爲二進制文件,動態連接到Windows本機C庫msvcrt.dll以及靜態地glibc部分。 Cygwin可執行文件所以更爲緊湊,但須要單獨的可再發行DLL,而MinGW二進制文件能夠獨立運行,但每每會更大。

基於Cygwin的程序須要單獨運行的DLL也會致使許可限制。 Cygwin運行時庫在GPLv3下得到許可,對於具備OSI兼允許可的應用程序,連接例外,所以但願圍繞Cygwin構建閉源應用程序的開發者必須從Red Hat得到商業許可。 另外一方面,MinGW代碼能夠用於開放源碼和封閉源碼的應用程序,由於頭文件和庫文件是被許可的。

Cygwin是一個相似於Unix的環境和Microsoft Windows的命令行界面。

Mingw是GNU編譯器集合(GCC)到Microsoft Windows的原生軟件端口,還有一套可自由分發的用於Windows API的導入庫和頭文件。 MinGW容許開發人員建立本機Microsoft Windows應用程序。

只要全部必要的庫(DLL)都存在,您就能夠在不使用cygwin環境的狀況下運行使用mingw生成的二進制文件。

Cygwin使用兼容性層,而MinGW是本地的。 這是不一樣的。

 

https://code.i-harness.com/zh-CN/q/bc6ac

相關文章
相關標籤/搜索