CygwinとMinGWの違いは何ですか？
回答:
簡略化すると、次のようになります。
Cygwinでコンパイルすると、Cygwin用にコンパイルされます。
MinGWで何かをコンパイルすると、Windows用にコンパイルされます。
Cygwinについて
Cygwinの目的は、Unixベースのオペレーティングシステムが提供する細かい詳細の多くをエミュレートすることにより、UnixベースのアプリケーションをWindowsに移植しやすくすることであり、POSIX標準で文書化されています。アプリケーションは、パイプ、UnixスタイルのファイルおよびディレクトリアクセスなどのUnix機能を使用でき、Cygwinでコンパイルして、アプリケーションの互換性レイヤーとして機能させることができるため、これらのUnix固有のパラダイムの多くは、引き続き使用されます。
ソフトウェアを配布するとき、受信者はそれをCygwinランタイム環境（ファイルによって提供されるcygwin1.dll）とともに実行する必要があります。これはソフトウェアと一緒に配布できますが、ソフトウェアはオープンソースライセンスに準拠する必要があります。ソフトウェアをリンクするだけで、dllを個別に配布する場合でも、オープンソースライセンスを尊重する必要がある場合もあります。
MinGWについて
MinGWは、GCC、Make、BashなどのGNUコンパイラツールのWindowsへの移植を目的としています。Unixをエミュレートしたり包括的な互換性を提供したりするのではなく、Windowsで GCC（GNUコンパイラー）と他の少数のツールを使用するために最低限必要な環境を提供します。CygwinのようなUnixエミュレーションレイヤーはありませんが、その結果、アプリケーションをWindowsで実行できるように特別にプログラムする必要があります。これは、標準のUnix環境での実行に依存するように作成された場合、大幅な変更を意味する可能性があります。前述のようなUnix固有の機能を使用します。デフォルトでは、MinGWのGCCでコンパイルされたコードは、.exeファイルや.dllファイルを含むネイティブのWindows X86ターゲットにコンパイルされますが、基本的にGNUコンパイラツールスイートを使用しているため、適切な設定でクロスコンパイルすることもできます。
MinGWは基本的に、Microsoft Visual C ++コンパイラとそれに関連するリンク/作成ツールの代替です。場合によっては、MinGWを使用して、Microsoft Visual C ++でのコンパイルを目的としたものを、適切なライブラリを使用してコンパイルしたり、場合によっては他の変更を加えたりしてコンパイルできます。
MinGWには、Windowsオペレーティングシステムと対話するためのいくつかの基本的な標準ライブラリが含まれていますが、GNUコンパイラコレクションに含まれる通常の標準ライブラリと同様に、これらは作成したソフトウェアにライセンス制限を課しません。
重要なソフトウェアアプリケーションの場合、包括的なクロスプラットフォームフレームワークを使用しない限り、それらをクロスプラットフォームにすることは大きな課題になる可能性があります。私がこれを書いた時点で、Qtフレームワークはこの目的で最も人気のあるフレームワークの 1つであり、Windowsを含むオペレーティングシステム全体で動作するグラフィカルアプリケーションの構築を可能にしましたが、他のオプションもあります。最初からこのようなフレームワークを使用すると、別のプラットフォームに移植するときに頭痛を軽減できるだけでなく、すべてのプラットフォームで同じグラフィカルウィジェット（ウィンドウ、メニュー、コントロール）を使用できます。 GUIアプリを使用して、ユーザーにネイティブに表示されるようにします。
Cygwinは、Windows上で完全なUNIX / POSIX環境を作成する試みです。これを行うには、さまざまなDLLを使用します。これらのDLLはGPLv3 +でカバーされていますが、それらのライセンスには、派生作業をGPLv3 +でカバーすることを強制しない例外が含まれています。MinGWは、このようなDLLに依存することなくWindows実行可能ファイルを作成できるC / C ++コンパイラスイートです。通常のMicrosoft Windowsインストールの一部である通常のMSVCランタイムのみが必要です。
MSYSと呼ばれるMinGWでコンパイルされた小さなUNIX / POSIXのような環境を取得することもできます。Cygwinのすべての機能の近くにはありませんが、MinGWを使用したいプログラマーにとって理想的です。
他の回答に追加するために、CygwinにはMinGWライブラリとヘッダーが付属しており、gccで-mno-cygwinフラグを使用してcygwin1.dllにリンクせずにコンパイルできます。プレーンなMinGWとMSYSを使用するよりも、これを非常に好みます。
gcc-3 -mno-cygwin
mingw64-x86_64-gcc-coreCygwinパッケージをインストールします。MinGW-64は、厄介な名前のx86_64-w64-mingw32-gccコマンドとして使用できるようになります。神を喜ばせてください、誰かがすでにこれらの血のようなものの名前を統一しています
Cygwinのウェブサイトから：
- Cygwinは、Windows用のLinuxのような環境です。これは2つの部分で構成されています。実質的なLinux API機能を提供するLinux APIエミュレーションレイヤーとして機能するDLL（cygwin1.dll）。
- Linuxのルックアンドフィールを提供するツールのコレクション。
Mingwのウェブサイトから：
MinGW（ "Minimalistic GNU for Windows"）は、自由に利用可能で自由に配布可能なWindows固有のヘッダーファイルとインポートライブラリのコレクションであり、GNUツールセットと組み合わせて、サードパーティのCランタイムDLLに依存しないネイティブWindowsプログラムを生成できます。
これらの回答された質問を読んで、CygwinとMinGWの違いを理解してください。
質問1：ソースコードを1回記述し、それを1回コンパイルして、任意のプラットフォーム（Windows、Linux、Mac OS Xなど）で実行するアプリケーションを作成したい。
回答＃1：ソースコードをJAVAで記述します。ソースコードを1回コンパイルして、どこでも実行します。
質問2：ソースコードを1度だけ作成するアプリケーションを作成したいのですが、任意のプラットフォーム（Windows、Linux、Mac OS Xなど）のソースコードを個別にコンパイルしても問題はありません。
回答＃2：ソースコードをCまたはC ++で記述します。標準のヘッダーファイルのみを使用します。任意のプラットフォームに適したコンパイラーを使用します（例：Visual Studio for Windows、GCC for LinuxおよびXCode for Mac）。すべてのプラットフォームでソースコードを正常にコンパイルするために、高度なプログラミング機能を使用しないでください。CまたはC ++の標準クラスまたは関数をまったく使用しない場合、ソースコードは他のプラットフォームでコンパイルされません。
質問＃3：質問＃2の回答で、プラットフォームごとに異なるコンパイラを使用することは困難です。クロスプラットフォームコンパイラはありますか？
回答＃3：はい、GCCコンパイラを使用します。クロスプラットフォームコンパイラです。Windowsでソースコードをコンパイルするには、Windows用のGCCコンパイラを提供し、ソースコードをネイティブのWindowsプログラムにコンパイルするMinGWを使用します。すべてのプラットフォームでソースコードを正常にコンパイルするために、高度なプログラミング機能（Windows APIなど）を使用しないでください。Windows API関数を使用する場合、ソースコードは他のプラットフォームでコンパイルされません。
質問4：CまたはC ++標準ヘッダーファイルは、マルチスレッドのような高度なプログラミング機能を提供しません。私に何ができる？
回答＃4：POSIX（Portable Operating System Interface [for UNIX]）標準を使用する必要があります。多くの高度なプログラミング機能とツールを提供します。完全または部分的にPOSIX互換の多くのオペレーティングシステム（Mac OS X、Solaris、BSD / OSなど）。一部のオペレーティングシステムは、POSIX互換として公式に認定されていませんが、大部分は準拠しています（Linux、FreeBSD、OpenSolarisなど）。Cygwinは、Microsoft Windows向けの大部分がPOSIX準拠の開発およびランタイム環境を提供します。
したがって：
WindowsでGCCクロスプラットフォームコンパイラの利点を使用するには、MinGWを使用します。
WindowsでPOSIX標準の高度なプログラミング機能とツールの利点を使用するには、Cygwinを使用します。
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の一部であり、ドキュメント化されておらず、バージョン管理されていないライブラリであり、アプリケーションの使用が制限されています。そのライブラリは基本的に、Windows自体で使用するためのMS Visual Cの再配布可能なランタイムライブラリのフォークです。
これらの両方の下で、プログラムは同様の動作をします：
- この
stat関数は、非常に限定された情報を返します。たとえば、有効な権限やiノード番号はありません。 - パス
c:file.txtは、driveに関連付けられている現在の作業ディレクトリに従って解決されc:ます。 systemcmd.exe /c外部コマンドの実行に使用します。
Cygwinでプログラムをコンパイルすることもできます。MS Visual Cで使用される再配布可能なランタイムと同様に、CygwinプログラムはCygwinのランタイムライブラリにリンクされます：cygwin1.dll（Cygwin本体）およびcyggcc_s-1.dll（GCCランタイムサポート）。Cygwinは現在LGPLの下にあるため、GPL互換のフリーソフトウェアでなくても、プログラムとともにパッケージ化してプログラムを出荷できます。
Cygwinでは、ライブラリ関数の動作が異なります。
- この
stat関数には豊富な機能があり、ほとんどのフィールドで意味のある値を返します。 - パス
c:file.txtc:後にスラッシュが付いていないはドライブ文字参照を含んでいるとはまったく理解されていません。コロンは名前の一部と見なされ、どういうわけかそれを壊されます。Cygwinのボリュームまたはドライブに対する相対パスの概念、「現在のログに記録されたドライブ」の概念、およびドライブごとの現在の作業ディレクトリはありません。 system関数は、使用しようと/bin/sh -c通訳を。Cygwinは/、実行可能ファイルの場所に従ってパスを解決し、sh.exeプログラムが実行可能ファイルと同じ場所に配置されることを期待します。
CygwinとMinGWの両方で、Win32関数を使用できます。MessageBoxまたはを呼び出したい場合はCreateProcess、それを行うことができます。また、コンソールウィンドウを必要としないプログラムを簡単に構築できます。gcc -mwindows、MinGWとCygwin、ます。
Cygwinは厳密にはPOSIXではありません。Windows APIへのアクセスを提供することに加えて、それはいくつかのMicrosoft C関数の独自の実装も提供します（中にあるもの、msvcrt.dllまたは再配布可能なmsvcrtnn.dllランタイム）。この例は、のspawn*ような関数のファミリーですspawnvp。これらは、Cygwinの代わりに、forkおよびexecCygwin で使用することをお勧めしますfork。これは、の概念を持たないWindowsプロセス作成モデルにより適切にマッピングされるためです。
したがって：
Cygwinプログラムは、ライブラリの伴奏を必要とするという理由で、MS Visual Cプログラムと同じように「ネイティブ」です。Windowsでのプログラミング言語の実装は、C言語の実装でさえ、独自のランタイムを提供することが期待されています。Windowsには一般向けの「libc」はありません。
MinGWがサードパーティのDLLを必要としないという事実は、実際には不利です。これは、ドキュメント化されていないWindows内部のVisual Cランタイムのフォークに依存しています。これは、GPLシステムライブラリの例外がに適用されるためです
msvcrt.dll。これは、GPLでコンパイルされたプログラムをMinGWでコンパイルおよび再配布できることを意味します。msvcrt.dllCygwinは、に比べてPOSIXのサポートがはるかに広くて深いため、POSIXプログラムを移植するための優れた環境です。現在はLGPLの下にあるため、オープンソースまたはクローズドソースのすべての種類のライセンスを持つアプリケーションを再配布できます。 Cygwinにtermiosは、Microsoftコンソールで動作するVT100エミュレーションとも含まれています。tcsetattrVT100コードを使用してrawモードを設定し、カーソルを制御するPOSIXアプリケーションは、cmd.exeウィンドウ内で正しく動作します。エンドユーザーに関する限り、これはWin32呼び出しを行ってコンソールを制御するネイティブコンソールアプリです。
しかしながら：
- ネイティブのWindows開発ツールとして、Cygwinには、Windowsにとって外部的なパス処理、ハードコーディングされたパスなどの依存関係など、いくつかの癖が
/bin/shあります。これらの違いにより、Cygwinプログラムは「非ネイティブ」になります。プログラムが引数としてパスを受け取るか、ダイアログボックスから入力を受け取る場合、Windowsユーザーは、そのパスが他のWindowsプログラムと同じように機能することを期待します。それがそのように機能しない場合、それは問題です。
プラグイン： LGPLの発表直後に、Cygnal（Cygwin Native Application Library）プロジェクトを開始して、これらの問題の修正を目的としたCygwin DLLのフォークを提供しました。プログラムはCygwinで開発してから、Cygnalバージョンのcygwin1.dll再コンパイルせずに。このライブラリが改善されると、MinGWの必要性が徐々になくなります。
Cygnalがパス処理の問題を解決すると、CygnalのWindowsアプリケーションとして出荷されるときにWindowsパスで動作し、Cygwinの/usr/bin下にインストールされたときにCygwinパスでシームレスに動作する単一の実行可能ファイルを開発することが可能になります。Cygwinでは、実行可能ファイルはのようなパスで透過的に機能します/cygdrive/c/Users/bob。Cygnalバージョンのにリンクしているネイティブデプロイメントではcygwin1.dll、そのパスは意味がありませんが、は理解しc:foo.txtます。
MinGWのバージョン1.3.3から分岐しましたCygwin。両方がCygwinとは、MinGWポートに使用することができますUNIXへのソフトウェアWindows、彼らは異なるアプローチがあります。Cygwin目的は完全に提供するために、POSIX layerいくつかのシステムコールと上に存在するライブラリのエミュレーション提供するLinux、UNIXとBSDバリアントを。はのPOSIX layer上で実行されWindows、互換性のために必要な場合はパフォーマンスを犠牲にします。したがって、このアプローチは必要とWindowsして書かれたプログラムCygwin、プログラムのと一緒に、プログラムと一緒に配布されなければならないコピーレフト互換ライブラリーの一番上で実行することをsource code。MinGWdirectを介してネイティブの機能とパフォーマンスを提供することを目的としていますWindows API calls。とは異なりCygwin、MinGWは互換性レイヤーDLLを必要としないため、プログラムをとともに配布する必要はありませんsource code。に
MinGW依存しているWindows API callsため、完全な提供はできませんPOSIX API。でコンパイルUNIX applicationsできるものはコンパイルできませんCygwin。具体的には、これはのPOSIXような機能 を必要とするアプリケーションfork()、mmap()またはioctl()での実行が想定される アプリケーションに適用されますPOSIX environment。使って書かれたアプリケーションcross-platform libraryそれ自体はに移植されているMinGWような、SDL、wxWidgets、Qt、またはGTK+、通常は簡単のようにコンパイルされますMinGW彼らは同じようにCygwin。の組み合わせ
MinGWとMSYS小さな自己完結型の環境を提供します。これは、コンピューターのレジストリーまたはファイルにエントリーを残さずに、リムーバブルメディアにロードできます。Cygwinポータブルにも同様の機能があります。より多くの機能を提供することにより、Cygwinインストールと保守がより複雑になります。それはすることも可能である
cross-compile Windows applicationsとMinGW-GCC under POSIX systems。開発者が使用してWindowsのインストールを必要としないことをこれが意味MSYS上で実行されますコンパイルソフトウェアWindowsなしCygwin。
WindowsでUnixアプリケーションをコンパイルするのに役立つAT＆TのU / Winソフトウェアを見逃さないでください（最新バージョン-2012-08-06; Eclipse Public License、バージョン1.0を使用）。
Cygwinのように、ライブラリに対して実行する必要があります。彼らの場合POSIX.DLL。AT＆Tの人たちは素晴らしいエンジニア（あなたにkshとdotをもたらしたのと同じグループ）であり、彼らのスタッフはチェックする価値があります。
他の答えはすでに目標を達成しています。簡単にキャッチできるようにイラストを追加したいだけです。
CygwinはPOSIX環境全体をエミュレートしますが、MinGWはコンパイル専用の最小限のツールセットです（ネイティブWinアプリケーションをコンパイルします）。したがって、プロジェクトをクロスプラットフォームにしたい場合、2つの間の選択は明白です、MinGW。
WindowsではVS、Linux / UnicesではGCCの使用を検討する場合があります。ほとんどのオープンソースプロジェクト（FirefoxやPythonなど）がそれを行います。
clang、実行可能なクロスプラットフォームソリューションであることです。
ユーティリティの動作は2つの間で完全に異なる可能性があることに注意してください。
たとえば、Cygwin tarはfork（）がDLLでサポートされているため、forw（）をフォークできますが、mingwバージョンではできません。これは、ソースからmysqlをコンパイルしようとするときの問題です。
商用/独自仕様/非オープンソースアプリケーションでCygwinを使用するには、Red Hatからの「ライセンス購入」に数万ドルを支払う必要があります。これは標準のライセンス条項を無効にしますは、かなりのコストでをます。Googleの「cygwinライセンスコスト」と最初のいくつかの結果を確認してください。
mingwの場合、そのようなコストは発生せず、ライセンス（PD、BSD、MIT）は非常に寛容です。せいぜい、あなたかもしれません、mingw64-tdmを使用するときに必要なwinpthreadsライセンスなど、アプリケーションにライセンスの詳細を提供が期待されます。
Izzy Helianthusによる編集： CygwinのwinsupサブディレクトリにあるAPIライブラリが、完全なGPLではなくLGPLで配布されるようになったため、商用ライセンスは利用できなくなりました。
Cygwinは、Windowsにほぼ完全なPOSIX環境を提供するように設計されています。これには、本格的なLinuxのようなプラットフォームを提供するように設計された広範なツールセットが含まれます。比較すると、MinGWとMSYSは、軽量でシンプルなPOSIXのようなレイヤーgccをbash提供します。MinGWのよりミニマリストなアプローチのため、Cygwinが提供するPOSIX APIカバレッジの程度を提供せず、したがって、Cygwinでコンパイルできる特定のプログラムを構築できません。
2つによって生成されたコードに関しては、Cygwinツールチェーンは大規模なランタイムライブラリへの動的リンクに依存していますがcygwin1.dll、MinGWツールチェーンは、WindowsネイティブCライブラリに動的にリンクするmsvcrt.dllとともに、の一部に静的にリンクするバイナリにコードをコンパイルしますglibc。したがって、Cygwin実行可能ファイルはよりコンパクトですが、再配布可能な個別のDLLが必要ですが、MinGWバイナリはスタンドアロンで出荷できますが、大きくなる傾向があります。
Cygwinベースのプログラムを実行するには別のDLLが必要であることも、ライセンスの制限につながります。Cygwinランタイムライブラリは、OSI準拠のライセンスを持つアプリケーションのリンク例外を除き、GPLv3の下でライセンスされます。そのため、Cygwinを中心にクローズドソースアプリケーションを構築する開発者は、Red Hatから商用ライセンスを取得する必要があります。一方、MinGWコードは、ヘッダーとライブラリのライセンスが許可されているため、オープンソースアプリケーションとクローズドソースアプリケーションの両方で使用できます。
Cygwin互換性レイヤーを使用しますが、MinGWネイティブです。これが主な違いの1つです。