我正在考虑一个跨平台的C ++服务器应用程序,该应用程序可能涉及大量的Internet流量和多线程密集型计算。我已经阅读了有关Cygwin和MinGW跨平台C ++应用程序的一些比较。根据Kaz关于5th answer of this StackOverflow question的新信息,我能否说Cygwin的未来更好?
2019年7月19日,Kaz添加了以下新信息(从那里复制):
插件::LGPL发布后不久,我启动了Cygnal(Cygwin本机应用程序库)项目,以提供旨在解决这些问题的Cygwin DLL的分支。程序可以在Cygwin下开发,然后与Cygnwin1.dll的Cygnal版本一起部署,而无需重新编译。随着该库的改进,它将逐渐消除对MinGW的需求。
当Cygnal解决路径处理问题时,有可能开发一个可执行文件,当与Cygnal一起作为Windows应用程序提供时,该可执行文件可以与Windows路径一起使用,而当安装在/ usr /中时,可以无缝与Cygwin路径一起使用。 Cygwin下的Bin。在Cygwin下,该可执行文件将透明地使用/ cygdrive / c / Users / bob之类的路径。在与cygwin1.dll的Cygnal版本链接的本机部署中,该路径没有意义,而它将理解c:foo.txt。
他说:随着该库的改进,它将逐渐消除对MinGW的需求。这到底是什么意思?
答案 0 :(得分:3)
我完全不这么认为。
首先,我不再考虑使用MinGW,因为MinGW-w64是更好,最新的替代品。
其次,Cygwin和MinGW-w64具有不同的目标。
Cygwin希望提供足够的Unix / POSIX仿真来编译本来很难移植到本机Windows的代码。因此,Cygwin二进制文件依赖于此仿真层,这意味着它们并不是真正的本机Windows,因为始终存在仿真层,这也带来了性能开销。
但是MinGW-w64旨在允许编译为本地Windows二进制文件。缺点是并非所有Unix / Linux / POSIX源都可以使用它进行编译(例如fork()
不存在),但是很多事情确实可以编译,并且它们会产生高性能的本机Windows二进制文件。
在过去的十年中,我个人根本不需要使用Cygwin。 我现在用MinGW-w64构建所有内容。实际上,我的电脑上甚至没有MSVC或任何其他编译器(例如Borland或Intel)。
我的建议始终是:仅在确实需要时才使用Cygwin。否则,MinGW-w64(尤其是与MSYS2结合使用)始终是您的最佳选择。 如果您计划构建用于商业发行的软件,则尤其如此。如果我要购买软件并发现Cygwin DLL是其中的一部分,那会让我皱眉,不知道该软件是否真的适用于Windows。
虽然MSYS2提供了不错的MinGW-w64 GCC编译器,但我决定启动http://winlibs.com/项目,以提供我自己的MinGW-w64 GCC,甚至LLVM / Clang以及将来的许多库对于本机win32和win64。
关于您的问题的结论: 如果您打算构建一些需要提高资源效率的东西,我真的建议您不要承担Cygwin的性能开销,而要使用MinGW-w64来实现最大的本机性能。