曾几何时，64位Cygwin缺少32位Cygwin中存在的许多软件包，但如今此类软件包的列表很短。由于这是在64位Windows系统上创建新的32位Cygwin安装的最后一个重要原因，因此您今天不太可能这样做。
使用64位Cygwin的最大优点是可以访问更多的内存。优势表现出两种非常不同的方式：
许多Cygwin程序将使用尽可能多的RAM。
例如，如果您将R的Cygwin版本用于大数据集，则应切换到64位Cygwin ASAP，因为R希望将整个数据集加载到RAM中，因此在64位上使用32位Cygwin机器人为地限制了R在Cygwin下可以完成的工作。
Cygwin面对fork()调用时处理DLL的方式要求将它们加载到固定的内存地址。
（这是一种rebase机制，通常在每次Cygwin的运行结束时自动运行setup.exe。）
其结果之一是，有可能在32位Cygwin中安装太多rebase地址空间不足的软件包，试图为其提供所有唯一的加载地址。出于所有实际目的，64位地址空间的指数级增大现在消除了这种可能性。
在某些情况下，64位Cygwin也可以更快。
您可以同时安装和运行两个版本的Cygwin。您甚至可以同时为每个菜单打开一个MinTTY窗口。但是，最好将它们视为独立的世界，因为两个Cygwin基本上是不兼容的。如果试图让它们进行互操作，将会遇到麻烦。
这种根本的不兼容性可能会以多种方式咬住您：
即使64位Cygwin程序可以启动32位Cygwin程序，反之亦然，但是一些跨进程机制将无法跨越该边界：POSIX共享内存，文件句柄传递，getppid(2)...
当您尝试使两个不同的Cygwins进行互操作时，甚至某些您不认为是跨进程的事情也会失败。/proc例如，Cygwin的大部分内容都来自DLL，因此，即使两个Cygwin在同一台计算机上同时运行，它们也将有所不同。
假设您想/usr/local在Cygwin之间共享，那么您不必拥有从源代码构建的所有软件的两个副本。
阅读以上第一项后，您意识到您无法共享/usr/local/bin或/usr/local/lib。
在考虑之后，您决定只想共享，/usr/local/src这样至少不必有重复的源树。如果像通常那样在源代码树中构建任何这些程序，仍然会遇到问题。（即./configure && make && make install）
发生这种情况有两个原因：
生成的二进制文件（*.o，*.so，*.a，*.exe...）将两个Cygwins之间不兼容的，所以除非你make cleanCygwins之间切换时，他们会被抛在后面，造成混乱。
即使您记得make clean，./configure每个Cygwin下的输出可能也会有所不同，因此尝试在64位Cygwin下构建在32位Cygwin下配置的程序（反之亦然）可能会失败。
有几种方法可以解决此陷阱：
也放弃分享/usr/local/src。
切记make clean && ./configure每次切换Cygwins时都要记住。
构建构建出的树分别为每个Cygwin的变种。
与以前的选项相比，它更清洁，更快且更可靠，但是并非所有源代码树都为此设置。
如果您没有充分的理由解决此类问题，请安装一个或另一个版本，而不要同时安装两个版本。
如果您具有可正常运行的32位Cygwin设置，并且不需要64位Cygwin的好处，则无需感觉必须将其替换为64位安装。32位Cygwin不会很快消失。
同时，如果我要安装一个新的64位Windows机器，则要在其上安装64位Cygwin，除非我事先知道它没有所需的移植端口，而且我不是愿意自己做港口。它是稳定的，而且基本上是完整的。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句