Cygwin과 MinGW의 차이점은 무엇입니까?

Cygwin과 MinGW의 차이점은 무엇입니까?

---

내 C ++ 프로젝트를 크로스 플랫폼으로 만들고 싶습니다. Cygwin / MinGW 사용을 고려하고 있습니다. 그러나 그들 사이의 차이점은 무엇입니까?

또 다른 질문은 Cygwin / MinGW없이 시스템에서 바이너리를 실행할 수 있는지 여부입니다.

---

단순화하면 다음과 같습니다.

• Cygwin에서 무언가를 컴파일하고 Cygwin 용 으로 컴파일합니다 .

• MinGW에서 무언가를 컴파일하면 Windows 용 으로 컴파일됩니다 .

Cygwin에 대해

Cygwin의 목적은 Unix 기반 운영 체제가 제공하고 POSIX 표준에 의해 문서화되는 많은 작은 세부 사항을 에뮬레이션하여 Unix 기반 응용 프로그램을 Windows로 훨씬 쉽게 이식 할 수 있도록하는 것입니다. 응용 프로그램은 파이프, Unix 스타일 파일 및 디렉토리 액세스 등과 같은 Unix 기능을 사용할 수 있으며 Cygwin으로 컴파일 할 수 있습니다. Cygwin은 응용 프로그램 주변 의 호환성 계층 역할을 하므로 이러한 많은 Unix 관련 패러다임이 가능합니다. 계속 사용됩니다.

소프트웨어를 배포 할 때받는 사람은 Cygwin 런타임 환경 (파일에서 제공)과 함께 소프트웨어를 실행해야합니다 cygwin1.dll. 이를 소프트웨어와 함께 배포 할 수 있지만 소프트웨어는 오픈 소스 라이선스를 준수해야합니다. 소프트웨어를 연결하는 것만으로도 dll을 별도로 배포하는 경우에도 여전히 오픈 소스 라이선스를 준수해야 할 수 있습니다.

MinGW 정보

MinGW는 단순히 GCC, Make, Bash 등과 같은 GNU 컴파일러 도구의 Windows 포트가되는 것을 목표로합니다. Unix를 에뮬레이션하거나 포괄적 인 호환성을 제공하지 않지만 대신 Windows에서 GCC (GNU 컴파일러) 및 소수의 기타 도구를 사용하는 데 필요한 최소한의 환경을 제공합니다.. Cygwin과 같은 Unix 에뮬레이션 계층이 없지만 결과적으로 응용 프로그램을 Windows에서 실행할 수 있도록 특별히 프로그래밍해야합니다. 따라서 표준 Unix 환경에서 실행되는 데 의존하도록 만들어진 경우 상당한 변경을 의미 할 수 있습니다. 앞서 언급 한 것과 같은 Unix 관련 기능을 사용합니다. 기본적으로 MinGW의 GCC에서 컴파일 된 코드는 기본적으로 GNU 컴파일러 도구 제품군을 사용하고 있기 때문에 올바른 설정으로 크로스 컴파일 할 수도 있지만 .exe 및 .dll 파일을 포함하여 네이티브 Windows X86 타겟으로 컴파일됩니다.

MinGW는 본질적으로 Microsoft Visual C ++ 컴파일러 및 관련 링크 / 메이크 도구 의 대안 입니다. 어떤 경우에는 MinGW를 사용하여 Microsoft Visual C ++로 컴파일하기 위해 고안된 것을 올바른 라이브러리와 다른 수정으로 컴파일하는 것이 가능할 수 있습니다.

MinGW에는 Windows 운영 체제와 상호 작용하기위한 몇 가지 기본 표준 라이브러리가 포함되어 있지만 GNU 컴파일러 컬렉션에 포함 된 일반 표준 라이브러리와 마찬가지로 사용자가 만든 소프트웨어에 라이선스 제한을 적용하지 않습니다.

사소하지 않은 소프트웨어 응용 프로그램의 경우 포괄적 인 크로스 플랫폼 프레임 워크를 사용하지 않는 한 크로스 플랫폼으로 만드는 것은 상당한 도전이 될 수 있습니다. 필자가이 글을 썼을 때 Qt 프레임 워크 는이 목적을 위해 가장 인기있는 프레임 워크 중 하나였으며, 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를 사용하는 것보다 이것을 매우 선호합니다.

---

Wikipedia는 여기서 비교 합니다 .

Cygwin 웹 사이트에서 :

• Cygwin은 Windows 용 Linux와 유사한 환경입니다. 두 부분으로 구성됩니다. 실질적인 Linux API 기능을 제공하는 Linux API 에뮬레이션 레이어 역할을하는 DLL (cygwin1.dll).
• Linux 모양과 느낌을 제공하는 도구 모음입니다.

Mingw의 웹 사이트에서 :

MinGW ( "Minimalistic GNU for Windows")는 타사 C 런타임 DLL에 의존하지 않는 네이티브 Windows 프로그램을 생성 할 수 있도록하는 GNU 도구 세트와 결합 된 무료로 사용 가능하고 무료로 배포 할 수있는 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에 대한 답변으로 각 플랫폼마다 다른 컴파일러를 사용하는 것이 어렵습니다. 크로스 플랫폼 컴파일러가 있습니까?

Answer #3: Yes, Use GCC compiler. It is a cross platform compiler. To compile your source code in Windows use MinGW that provides GCC compiler for Windows and compiles your source code to native Windows program. Do not use any advanced programming features (like Windows API) to compile your source code in all platforms successfully. If you use Windows API functions, your source code does not compile in other platforms.

---

Question #4: C or C++ standard header files do not provide any advanced programming features like multi-threading. What can I do?

Answer #4: You should use POSIX (Portable Operating System Interface [for UNIX]) standard. It provides many advanced programming features and tools. Many operating systems fully or partly POSIX compatible (like Mac OS X, Solaris, BSD/OS and ...). Some operating systems while not officially certified as POSIX compatible, conform in large part (like Linux, FreeBSD, OpenSolaris and ...). Cygwin provides a largely POSIX-compliant development and run-time environment for Microsoft Windows.

---

Thus:

To use advantage of GCC cross platform compiler in Windows, use MinGW.

To use advantage of POSIX standard advanced programming features and tools in Windows, use Cygwin.

---

Wikipedia Says:

MinGW forked from version 1.3.3 of Cygwin. Although both Cygwin and MinGW can be used to port UNIX software to Windows, they have different approaches: Cygwin aims to provide a complete POSIX layer that provides emulations of several system calls and libraries that exist on Linux, UNIX, and the BSD variants. The POSIX layer runs on top of Windows, sacrificing performance where necessary for compatibility. Accordingly, this approach requires Windows programs written with Cygwin to run on top of a copylefted compatibility library that must be distributed with the program, along with the program's source code. MinGW aims to provide native functionality and performance via direct Windows API calls. Unlike Cygwin, MinGW does not require a compatibility layer DLL and thus programs do not need to be distributed with source code.

Because MinGW is dependent upon Windows API calls, it cannot provide a full POSIX API; it is unable to compile some UNIX applications that can be compiled with Cygwin. Specifically, this applies to applications that require POSIX functionality like fork(), mmap() or ioctl() and those that expect to be run in a POSIX environment. Applications written using a cross-platform library that has itself been ported to MinGW, such as SDL, wxWidgets, Qt, or GTK+, will usually compile as easily in MinGW as they would in Cygwin.

The combination of MinGW and MSYS provides a small, self-contained environment that can be loaded onto removable media without leaving entries in the registry or files on the computer. Cygwin Portable provides a similar feature. By providing more functionality, Cygwin becomes more complicated to install and maintain.

It is also possible to cross-compile Windows applications with MinGW-GCC under POSIX systems. This means that developers do not need a Windows installation with MSYS to compile software that will run on Windows without Cygwin.

---

From the point of view of porting a C program, a good way to understand this is to take an example:

#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;
}

If we change stat to _stat, we can compile this program with Microsoft Visual C. We can also compile this program with MinGW, and with Cygwin.

Under Microsoft Visual C, the program will be linked to a MSVC redistributable run-time library: mxvcrtnn.dll, where nn is some version suffix. To ship this program we will have to include that DLL. That DLL provides _stat, system and printf. (We also have the option of statically linking the run-time.)

Under MinGW, the program will be linked to msvcrt.dll, which is an internal, undocumented, unversioned library that is part of Windows, and off-limits to application use. That library is essentially a fork of the redistributable run-time library from MS Visual C for use by Windows itself.

Under both of these, the program will have similar behaviors:

• the stat function will return very limited information—no useful permissions or inode number, for instance.
• the path c:file.txt is resolved according to the current working directory associated with drive c:.
• system uses cmd.exe /c for running the external command.

We can also compile the program under Cygwin. Similarly to the redistributable run-time used by MS Visual C, the Cygwin program will be linked to Cygwin's run-time libraries: cygwin1.dll (Cygwin proper) and cyggcc_s-1.dll (GCC run-time support). Since Cygwin is now under the LGPL, we can package with our program, even if it isn't GPL-compatible free software, and ship the program.

Under Cygwin, the library functions will behave differently:

• the stat function has rich functionality, returning meaningful values in most of the fields.
• the path c:file.txt is not understood at all as containing a drive letter reference, since c: isn't followed by a slash. The colon is considered part of the name and somehow mangled into it. There is no concept of a relative path against a volume or drive in Cygwin, no "currently logged drive" concept, and no per-drive current working directory.
• the system function tries to use the /bin/sh -c interpreter. Cygwin will resolve the / path according to the location of your executable, and expect a sh.exe program to be co-located with your executable.

Both Cygwin and MinGW allow you to use Win32 functions. If you want to call MessageBox or CreateProcess, you can do that. You can also easily build a program which doesn't require a console window, using gcc -mwindows, under MinGW and Cygwin.

Cygwin is not strictly POSIX. In addition to providing access to the Windows API, it also provides its own implementations of some Microsoft C functions (stuff found in msvcrt.dll or the re-distributable msvcrtnn.dll run-times). An example of this are the spawn* family of functions like spawnvp. These are a good idea to use instead of fork and exec on Cygwin since they map better to the Windows process creation model which has no concept of fork.

Thus:

• Cygwin programs are no less "native" than MS Visual C programs on grounds of requiring the accompaniment of libraries. Programming language implementations on Windows are expected to provide their own run-time, even C language implementations. There is no "libc" on Windows for public use.

• The fact that MinGW requires no third-party DLL is actually a disadvantage; it is depending on an undocumented, Windows-internal fork of the Visual C run-time. MinGW does this because the GPL system library exception applies to msvcrt.dll, which means that GPL-ed programs can be compiled and redistributed with MinGW.

• Due to its much broader and deeper support for POSIX compared to msvcrt.dll, Cygwin is by far the superior environment for porting POSIX programs. Since it is now under the LGPL, it allows applications with all sorts of licenses, open or closed source, to be redistributed. Cygwin even contains VT100 emulation and termios, which work with the Microsoft console! A POSIX application that sets up raw mode with tcsetattr and uses VT100 codes to control the cursor will work right in the cmd.exe window. As far as the end-user is concerned, it's a native console app making Win32 calls to control the console.

However:

• As a native Windows development tool, Cygwin has some quirks, like path handling that is foreign to Windows, dependence on some hard-coded paths like /bin/sh and other issues. These differences are what render Cygwin programs "non-native". If a program takes a path as an argument, or input from a dialog box, Windows users expect that path to work the same way as it does in other Windows programs. If it doesn't work that way, that's a problem.

Plug: Shortly after the LGPL announcement, I started the Cygnal (Cygwin Native Application Library) project to provide a fork of the Cygwin DLL which aims to fix these issues. Programs can be developed under Cygwin, and then deployed with the Cygnal version of cygwin1.dll without recompiling. As this library improves, it will gradually eliminate the need for MinGW.

When Cygnal solves the path handling problem, it will be possible to develop a single executable which works with Windows paths when shipped as a Windows application with Cygnal, and seamlessly works with Cygwin paths when installed in your /usr/bin under Cygwin. Under Cygwin, the executable will transparently work with a path like /cygdrive/c/Users/bob. In the native deployment where it is linking against the Cygnal version of cygwin1.dll, that path will make no sense, whereas it will understand c:foo.txt.

---

Don't overlook AT&T's U/Win software, which is designed to help you compile Unix applications on windows (last version - 2012-08-06; uses Eclipse Public License, Version 1.0).

Like Cygwin they have to run against a library; in their case POSIX.DLL. The AT&T guys are terrific engineers (same group that brought you ksh and dot) and their stuff is worth checking out.

---

Cygwin emulates entire POSIX environment, while MinGW is minimal tool set for compilation only (compiles native Win application.) So if you want to make your project cross-platform the choice between the two is obvious, MinGW.

Although you might consider using VS on Windows, GCC on Linux/Unices. Most open source projects do that (e.g. Firefox or Python).

---

To use Cygwin in a commercial / proprietary / non-open-source application, you'll need to fork out tens of thousands of dollars for a "license buyout" from Red Hat; this invalidates the standard licensing terms at a considerable cost. Google "cygwin license cost" and see first few results.

For mingw, no such cost is incurred, and the licenses (PD, BSD, MIT) are extremely permissive. At most you may be expected to supply license details with your application, such as the winpthreads license required when using mingw64-tdm.

EDIT thanks to Izzy Helianthus: The commercial license is no longer available or necessary because the API library found in the winsup subdirectory of Cygwin is now being distributed under the LGPL, as opposed to the full GPL.

---

Note that utility behaviour can genuinely vary between the two.

For example, Cygwin tar can fork - because fork() is supported in the DLL - where the mingw version cannot. This is a problem when trying to compile mysql from source.

---

Cygwin is designed to provide a more-or-less complete POSIX environment for Windows, including an extensive set of tools designed to provide a full-fledged Linux-like platform. In comparison, MinGW and MSYS provide a lightweight, minimalist POSIX-like layer, with only the more essential tools like gcc and bash available. Because of MinGW's more minimalist approach, it does not provide the degree of POSIX API coverage Cygwin offers, and therefore cannot build certain programs which can otherwise be compiled on Cygwin.

In terms of the code generated by the two, the Cygwin toolchain relies on dynamic linking to a large runtime library, cygwin1.dll, while the MinGW toolchain compiles code to binaries that link dynamically to the Windows native C library msvcrt.dll as well as statically to parts of glibc. Cygwin executables are therefore more compact but require a separate redistributable DLL, while MinGW binaries can be shipped standalone but tend to be larger.

The fact that Cygwin-based programs require a separate DLL to run also leads to licensing restrictions. The Cygwin runtime library is licensed under GPLv3 with a linking exception for applications with OSI-compliant licenses, so developers wishing to build a closed-source application around Cygwin must acquire a commercial license from Red Hat. On the other hand, MinGW code can be used in both open-source and closed-source applications, as the headers and libraries are permissively licensed.

---

Other answers already hit the target. I just want to add an illustration for a quick catch.

---

Cygwin is is a Unix-like environment and command-line interface for Microsoft Windows.

Mingw is a native software port of the GNU Compiler Collection (GCC) to Microsoft Windows, along with a set of freely distributable import libraries and header files for the Windows API. MinGW allows developers to create native Microsoft Windows applications.

You can run binaries generated with mingw without the cygwin environment, provided that all necessary libraries (DLLs) are present.

---

Cygwin uses a compatibility layer, while MinGW is native. That is one of the main differences.

참고URL : https://stackoverflow.com/questions/771756/what-is-the-difference-between-cygwin-and-mingw