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?
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:
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.
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:
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)...
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.
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.
Corinna Vinschen, co-lead developer of Cygwin, has said the following, as part of the Cygwin 1.7.25 release notes:
ABOUT THE 64 BIT RELEASE
This is only the fourth official Cygwin release which is publically available as a 64 bit version for AMD64 Windows systems, so it's still pretty new.
Right now the 64 bit Cygwin distribution doesn't come with as many packages as the 32 bit version, but it's as stable as the 32 bit version, and more packages will be available over time.
If you're already running a 32 bit version of Cygwin on 64 bit Windows machines, you can continue to do so. If you're planning a new install of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit Cygwin version, unless you need certain packages not yet available in the 64 bit release.
The other problem with "upgrading" to 64-bit is that there is not, AFAIK, a way to automatically re-install the same list of packages that you had in the 32-bit installation, so you will have to painstakingly make a list of installed packages and painstakingly check them all off in the new installation just to get back to where you were before you re-installed.
cygcheck -c | sed -e 's/ .*//' | sed '1,2d' > packageList.out will create a nice little list of all your installed packages. You can then run the setup*.exe from the command line with the -P switch and your packages, which you can grab from your output file with this: $(paste -d, -s packageList.out). I have scripts for all of this so I can regen my Cygwin environment on multiple machines in 32 and 64-bit. You want to do a base install first, then add your other installed packages. –
Livonia There are some big advantages with Cygwin x64. One of them is the better memory management. I experimented a lot of address already in use, or fork: retry: Resource temporarily unavailable that forced me to run a rebaseall sometime several times a day.
With Cygwin x64 I never had any issues like this.
fork: retry: Resource temporarily unavailable. I'm installing the x64 bit version this time. –
Mohave Install both. It doesn't take much time or disk space, and some packages aren't available for cygwin64. (Put them in different directories!)
I don't know whether sqlite3 in cygwin64 can index databases that are over about 4G in size, but I know sqlite3 in cygwin32 can't, and sqlite3 in 64-bit Linux can.
cygwin64 still doesn't have pdftk (the PDF toolkit).
Not enough reputation to comment on the selected answer, so here goes:
What about installing Cygwin64 in c:\cygwin (via setup-x86_64.exe), do a secondary Cygwin32 install in c:\cygwin32 (via setup-x86.exe), then add /cygdrive/c/cygwin32/<for_each_of_the_bin_dirs> at the end of $PATH?
This should run 64-bit apps by default, but permit calling 32-bit apps if the 64-bit version is not present.
It would be useful if setup-x86_64.exe were able to present a version-aware unified list of all Cygwin apps, and do the 32-bit install only when needed (with a popup suggesting doing a 64-bit port).
libwhatever.dll that is available both in 64-bit and 32-bit Cygwin. Most likely, it'll crash. –
Sandon © 2022 - 2024 — McMap. All rights reserved.