Is it advisable to switch from Cygwin 32bit to Cygwin 64bit?

Question

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.

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?

Answer 1

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.

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. Many Cygwin programs will make use of as much RAM as you can give them.

   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.

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

   (This is the rebase mechanism, normally run automatically at the end of each run of Cygwin's setup.exe.)

   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-bit Cygwin can also be a bit faster, in some cases.

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. Even though a 64-bit Cygwin program can launch a 32-bit Cygwin program and vice versa, several cross-process mechanisms won't work across that boundary: POSIX shared memory, file handle passing, getppid(2)...

2. 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.

3. 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.

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

   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:

   • 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.

   • 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:

   • Give up on sharing /usr/local/src, too.

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

   • Build build out-of-tree separately for each Cygwin variant.

     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.

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.

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.