是否建议从Cygwin 32bit切换到Cygwin 64bit？ [英] Is it advisable to switch from Cygwin 32bit to Cygwin 64bit?

问题描述

我一直在使用 Cygwin （很长一段时间）。具体来说，我在Win7上使用它（包括gcc / g ++）进行开发工作。我刚刚注意到，现在存在一个 64位版本。

I've been using Cygwin (for a long time). Specifically, I use it (including gcc/g++) on Win7 for development work. I've just recently noticed there now exists a 64-bit version.

我没有特定的需求，我需要过渡到64位，但是我想知道是否还是要这样做。这是明智的吗？优缺点都有什么？进行过渡时是否存在已知的过度竞争问题？

I don't have a specific need which requires that I make the transition to 64-bit, but I was wondering whether to do it anyway. Is it advisable? What are the pros and cons? Are there known over-arcing issues when making the transition?

推荐答案

从前，64位Cygwin缺少许多软件包目前存在于32位Cygwin中，但今天此类软件包的列表相当短。因为这是在64位Windows系统上创建新的32位Cygwin安装的最后一个重要原因，所以今天不太可能有充分的理由这样做。

Once upon a time, 64-bit Cygwin was missing many packages present in 32-bit Cygwin, but today the list of such packages is quite short. Since that was the last significant reason to create new 32-bit Cygwin installs on 64-bit Windows systems, it is unlikely that you have a good reason to do that today.

使用64位Cygwin的最大优点是可以访问更多的内存。优势表现出两种非常不同的方式：

The biggest advantage to using 64-bit Cygwin is access to greater amounts of memory. There are two very different ways the advantage presents itself:

1. 许多Cygwin程序将使用尽可能多的RAM。

1. Many Cygwin programs will make use of as much RAM as you can give them.

如果您使用的是 R 例如，对于大型数据集，您应该切换到64位Cygwin ASAP，因为R希望将整个数据集加载到RAM中，因此在64位计算机上使用32位Cygwin会人为地限制R可以执行的操作

If you're using the Cygwin version of R with large data sets, for example, you should switch to 64-bit Cygwin ASAP because R wants to load the entire data set into RAM, so using 32-bit Cygwin on a 64-bit machine artificially limits what R can accomplish under Cygwin.

面对 fork（）调用，Cygwin处理DLL的方式需要

The way Cygwin deals with DLLs in the face of fork() calls requires that they be loaded at a fixed memory address.

（这是 rebase 机制，通常在Cygwin的 setup.exe 。）

一个结果是，可能在32位Cygwin中安装了很多软件包，以致 rebase 用尽了地址空间，试图为它们提供所有唯一的加载地址。出于所有实际目的，64位地址空间的指数级增大现在消除了这种可能性。

One consequence of this is that it was possible in 32-bit Cygwin to install so many packages that rebase ran out of address space trying to give them all unique loading addresses. The exponentially larger size of the 64-bit address space eliminates this possibility now, for all practical purposes.

64-在某些情况下，Cygwin的运行速度也可能会更快。

64-bit Cygwin can also be a bit faster, in some cases.

您可以同时安装和运行两个版本的Cygwin。您甚至可以同时为每个菜单打开一个MinTTY窗口。不过，最好将它们视为独立的世界，因为两个Cygwins 根本不兼容。如果您试图让它们进行互操作，则会遇到麻烦。

You can have both versions of Cygwin installed and running at the same time. You can even have a MinTTY window for each up at the same time. Nevertheless, it is best to treat them as separate worlds, since the two Cygwins are fundamentally incompatible. You will run into trouble if you try to get them to interoperate.

这种基本的不兼容性会以多种方式咬住您：

This fundamental incompatibility can bite you in several ways:

1. 即使一个64位的Cygwin程序可以启动一个32位的Cygwin程序，反之亦然，但是一些跨进程机制将无法跨越该边界：POSIX共享内存，文件句柄传递， getppid（2） ...

即使您不做某些事情当您尝试使两个不同的Cygwins互操作时，跨进程将失败。例如，Cygwin的 / proc 的大部分内容都来自DLL，因此，即使两个Cygwin在同一台计算机上同时运行，它们的内容也有所不同。

Even some things you don't think of as being cross-process will fail when you try to make two different Cygwins interoperate. Much of the contents of Cygwin's /proc comes from within the DLL, for example, so it will be different between two Cygwins, even though they're running simultaneously on the same machine.

说您想在Cygwins之间共享 / usr / local ，这样您就不必拥有从源代码构建的所有软件的两个副本。

Say you wanted to share /usr/local between the Cygwins so you don't have to have two copies of all software you've built from source.

阅读上面的第一项后，您意识到您无法共享 / usr / local / bin 或 / usr / local / lib 。

After reading the first item above, you realize that you can't share /usr/local/bin or /usr/local/lib.

之后考虑一下，您决定只想共享 / usr / local / src ，这样至少不必有重复的源树。通常，如果您在源代码树中构建任何这些程序，仍然会遇到问题。 （即。/configure&&&& make install ）

After thinking on it, you decide you just want to share /usr/local/src so that you at least don't have to have duplicate source trees. You're still going to have problems if you build any of these programs in the source tree, as is typical. (i.e. ./configure && make && make install)

发生这种情况有两个原因：

This happens for two reasons:

• 生成的二进制文件（ *。o ， *。so ， *。a ， *。exe ...）在两个Cygwin之间是不兼容的，因此除非在两个Cygwin之间切换时干净，否则它们将被抛在后面，造成混乱。

• Generated binaries (*.o, *.so, *.a, *.exe...) will be incompatible between the two Cygwins, so unless you make clean when switching between Cygwins, they're going to be left behind, causing confusion.

即使您记得清理，也会输出。/configure 在每个Cygwin下可能会有所不同，因此尝试在64位Cygwin下构建在32位Cygwin下配置的程序（反之亦然）可能会失败。

Even if you remember to make clean, the output of ./configure under each Cygwin will probably be different, so attempting to build a program under 64-bit Cygwin that was configured under 32-bit Cygwin (or vice versa) could fail.

有几种方法可以解决此问题：

There are several ways out of this trap:

• 放弃共享 / usr / local / src 。

记住 make清洁&& ./configure 每当您切换Cygwins。

Remember to make clean && ./configure whenever you switch Cygwins.

构建为每个Cygwin变体分别构建树外。

与以前的选项相比，此方法更干净，更快且更可靠，但并非所有源树都已设置为允许这样做。

This is cleaner, faster, and more reliable than the previous option, but not all source trees are set up to allow this.

如果您没有充分的理由解决此类问题，请安装一个版本或另一个版本，而不要同时安装两个版本。

If you don't have a good reason to put up with such problems, install one version or the other, not both.

如果您具有运行正常的32位Cygwin设置，并且不需要64位Cygwin的好处，则不必感觉必须用64位安装代替它。 32位Cygwin不会很快消失。

If you have a functioning 32-bit Cygwin setup and don't need the benefits of 64-bit Cygwin, you needn't feel that you must replace it with a 64-bit install. 32-bit Cygwin isn't going away any time soon.

同时，如果我要设置一个新的64位Windows机器，我会安装在它上面的64位Cygwin，除非我事先知道它没有我需要的移植端口，而且我也不愿意自己移植。它稳定且基本完整。

At the same time, if I were setting up a new 64-bit Windows box, I'd install 64-bit Cygwin on it unless I knew up front it didn't have a package ported that I needed, and I wasn't willing to do the port myself. It's stable and mostly complete.

这篇关于是否建议从Cygwin 32bit切换到Cygwin 64bit？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！