我想讓個人C ++項目跨平臺,我正在考慮使用Cygwin / MinGW。 可是他們之間有什麼區別呢?html
另外一個問題是,若是沒有Cygwin / MinGW,我可否在系統上運行二進制文件?node
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標準的開發和運行環境。
從而:
維基百科說 :
MinGW
從Cygwin
1.3.3版本中分離出來。 雖然Cygwin
和MinGW
均可以用來將UNIX
軟件移植到Windows
,但他們有不一樣的方法:Cygwin
目標是提供一個完整的POSIX layer
,提供Linux
,UNIX
和BSD
變種中存在的幾個系統調用和庫的模擬。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
運行的應用程序。 使用自己已經移植到MinGW
的cross-platform library
(例如SDL
,wxWidgets
,Qt
或GTK+
編寫的應用程序一般在MinGW
編譯將像在Cygwin
那樣容易。
MinGW
和MSYS
的組合提供了一個小型自包含的環境,能夠將其加載到可移動媒體上,而無需在註冊表或計算機上的文件中留下條目。Cygwin
Portable提供了相似的功能。 經過提供更多的功能,Cygwin
安裝和維護變得更加複雜。也能夠
MinGW-GCC under POSIX systems
用MinGW-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
, system
和printf
。
在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函數。 若是你想調用MessageBox
或CreateProcess
,你能夠這樣作。 你也能夠在MinGW和Cygwin下使用gcc -mwindows
輕鬆地建立一個不須要控制檯窗口的程序。
Cygwin不是嚴格的POSIX。 除了提供對Windows API的訪問以外,它還提供了一些Microsoft C函數(在msvcrt.dll
找到的東西或可從新分發的msvcrtnn.dll
運行時)的本身的實現。 一個例子就是spawn*
系列的spawn*
系列。 這些在Cygwin上使用而不是fork
和exec
是一個好主意,由於它們更好地映射到沒有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調用來控制控制檯。
然而:
/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層,只有像gcc
和bash
這樣的更重要的工具可用。 因爲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