快捷搜索:

您的位置:澳门新葡4473网站 > 热门贴子 > windows - Cygwin和MinGW有什么区别?(MinGW从Cygwin 1

windows - Cygwin和MinGW有什么区别?(MinGW从Cygwin 1

发布时间:2020-02-15 05:50编辑:热门贴子浏览(197)

    Cygwin 3.1.0 发布了,Cygwin是许多自由软件的集合,最初由Cygnus Solutions开发,用于各种版本的Microsoft Windows上,运行UNIX类系统。Cygwin的主要目的是通过重新编译,将POSIX系统(例如Linux、BSD,以及其他Unix系统)上的软件移植到Windows上。Cygwin移植工作在Windows NT、Windows 2000、Windows XP以及Windows Server 2003上比较好,在Windows 95和Windows 98上,相对差劲一些。目前Cygwin由Red Hat等负责维护。

    我想让我的C ++项目跨平台,我正在考虑使用Cygwin / MinGW。 但是他们之间有什么区别呢?

    新版本包括:

    另一个问题是,如果没有Cygwin / MinGW,我能否在系统上运行二进制文件?

    * cygwin-3.1.0-1
    * cygwin-devel-3.1.0-1
    * cygwin-doc-3.1.0-1
    

     Answers


    Cygwin是尝试在Windows上创建一个完整的UNIX / POSIX环境。 要做到这一点,它使用各种DLL。 虽然这些DLL被GPLv3 +覆盖,但是它们的许可证包含一个异常 ,不会强制派生的工作被GPLv3 +覆盖。 MinGW是一个C / C ++编译器套件,它允许您创建Windows可执行文件而不依赖于这样的DLL - 您只需要普通的MSVC运行时,这是Microsoft Windows正常安装的一部分。

    你也可以得到一个小的UNIX / POSIX环境,用MinGW编译成MSYS 。 它没有Cygwin的所有功能,但对于想要使用MinGW的程序员来说是非常理想的。

    作为一个简化,就是这样的:

    • 在Cygwin中编译一些东西,然后编译Cygwin 。

    • 编译MinGW中的东西,你正在为Windows编译它。

    关于Cygwin

    Cygwin的目的是通过模拟许多基于Unix的操作系统提供的小细节,并通过POSIX标准来记录,使得基于nix的应用程序更容易移植到Windows上。 如果您的应用程序假定它可以使用Unix功能,例如管道,Unix风格的文件和目录访问等等,那么您可以在Cygwin中编译它,而Cygwin本身将作为您的应用程序的兼容层 ,这些特定于Unix的范例可以继续使用,对应用程序进行很少或不需要修改。

    如果你想为Cygwin编译一些东西并分发这个应用程序,那么你还必须将Cygwin运行时环境(由cygwin1.dll提供)与它一起cygwin1.dll , 这对你可能使用哪种类型的软件许可有影响 。

    关于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 ++编译器及其关联的链接/制作工具的开源替代品。

    该版本包含一些新特性和 bug 修复,主要有:

    存在相当复杂的跨平台框架,这使得将应用轻松移植到各种操作系统的任务成为可能

    例如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标准的开发和运行环境。

    从而:

    - Add 24 bit color support using xterm compatibility mode in Windows 10
      1703 or later.  Add fake 24 bit color support for legacy console,
      which uses the nearest color from 16 system colors.
    
    - Support pseudo console in PTY. Pseudo console is a new feature
      in Windows 10 1809, which provides console APIs on virtual
      terminal. With this patch, native console applications can work
      in PTYs such as mintty, ssh, gnu screen or tmux.
    
    - New APIs: sched_getaffinity, sched_setaffinity, pthread_getaffinity_np,
      pthread_setaffinity_np, plus CPU_SET macros.
    
    - New APIs: dbm_clearerr, dbm_close, dbm_delete, dbm_dirfno, dbm_error,
      dbm_fetch, dbm_firstkey, dbm_nextkey, dbm_open, dbm_store.
    
    
    What changed:
    -------------
    
    - FIFOs can now be opened multiple times for writing.
      Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00047.html
                 https://cygwin.com/ml/cygwin/2015-12/msg00311.html
    
    - If a SA_SIGINFO signal handler changes the ucontext_t pointed to by
      the third parameter, follow it after returning from the handler.
    
    - Eliminate a header file name collision with <X11/XLocale.h> on case
      insensitive filesystems by reverting <xlocale.h> back to <sys/_locale.h>.
    
    - Allow times(2) to have a NULL argument, as on Linux.
      Addresses: https://cygwin.com/ml/cygwin/2019-09/msg00141.html
    
    - Improve /proc/cpuinfo output and align more closely with Linux.
    
    - Raise stackdump frame limit from 16 to 32.
      Addresses: https://cygwin.com/ml/cygwin/2019-11/msg00038.html
    
    
    Bug Fixes
    ---------
    
    - Fix select() on console in canonical mode.  Return after one line is
      completed, instead of when only one key is typed.
    
    - Make console I/O functions thread-safe.
    
    - Define missing MSG_EOR.  It's unsupported by the underlying Winsock
      layer so using it in send(2), sendto(2), or sendmsg(2) will return -1
      with errno set to EOPNOTSUPP and recvmsg(2) will never return it.
    
    - Fix a timerfd deadlock.
      Addresses: https://cygwin.com/ml/cygwin/2019-06/msg00096.html
    
    - Fix sigpending() incorrectly returning signals for unrelated threads.
      Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00051.html
    
    - Fix a hang when opening a FIFO with O_PATH.
      Addresses: https://cygwin.com/ml/cygwin-developers/2019-06/msg00001.html
    
    - Don't append ".lnk" when renaming a socket file.
      Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00139.html
    
    - Make tcsetpgrp() return -1 if its argument is negative.
      Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00166.html
    
    - Avoid mistakenly moving a process under debugger control into the
      process group of the debugger.
      Addresses a problem visible in GDB 8.1.1, related to
      https://cygwin.com/ml/cygwin/2019-07/msg00166.html
    
    - Return ENOEXEC from execve for arbitrary files only if the files are
      executable.
      Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00054.html
    
    - Fix off-by-one in environment evaluation leading to an abort.
      Addresses: https://cygwin.com/ml/cygwin-patches/2019-q3/msg00069.html
    
    - Make output of /proc/[PID]/stat consistent with getpriority().
      Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00082.html
    
    - 64 bit only: Avoid collisions between memory maps created with shmat
      and Windows datastructures during fork.
      Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00107.html
    
    - Make rmdir fail if its argument is a symlink.
      Addresses: https://cygwin.com/ml/cygwin/2019-09/msg00221.html
    
    - Fix an assertion failure on an invalid path.
      Addresses: https://cygwin.com/ml/cygwin/2019-09/msg00228.html
    
    - If the argument to mkdir(2) or rmdir(2) is 'x:', don't strip the
      trailing backslash.
      Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00334.html
    
    - Make spawnvp, spawnvpe fail if the executable is not in $PATH.
      Addresses: https://cygwin.com/ml/cygwin/2019-10/msg00032.html
    
    - Fix parent/child relationship after parent dies.
      Addresses: https://cygwin.com/ml/cygwin/2019-09/msg00263.html
    
    - Fix a security problem if Cygwin is installed into a path
      with spaces in it.
      Addresses: https://cygwin.com/ml/cygwin/2019-11/msg00018.html
    
    - Fix an assertion failure when /cygdrive contains an offline network
      drive.
      Addresses: https://cygwin.com/ml/cygwin/2019-12/msg00016.html
    
    - Fix return value of ilogbl for 0 input.
      Addresses: https://cygwin.com/ml/cygwin/2019-12/msg00074.html
    
    - Let strtold set errno to ERANGE on underflow per POSIX.
      Addresses: https://cygwin.com/ml/cygwin/2019-12/msg00072.html
    

    要在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, Worldn");
       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是本地的。 这是不同的。

     

    本文由澳门新葡4473网站发布于热门贴子,转载请注明出处:windows - Cygwin和MinGW有什么区别?(MinGW从Cygwin 1

    关键词: