FAQ

1.1. What is it?
The Cygwin tools are ports of the popular GNU development tools for Microsoft Windows. They run thanks to the Cygwin library which provides the UNIX system calls and environment these programs expect.

With these tools installed, it is possible to write Win32 console or GUI applications that make use of the standard Microsoft Win32 API and/or the Cygwin API. As a result, it is possible to easily port many significant Unix programs without the need for extensive changes to the source code. This includes configuring and building most of the available GNU software (including the packages included with the Cygwin development tools themselves). Even if the development tools are of little to no use to you, you may have interest in the many standard Unix utilities provided with the package. They can be used both from the bash shell (provided) or from the standard Windows command shell.

1.2. What versions of Windows are supported?

Cygwin can be expected to run on all modern 32 bit versions of Windows, except Windows CE. This included Windows 95/98/ME/NT/2000 as well as XP/2003 and the WOW64 32 bit environment on released 64 bit versions of Windows. Recent releases run on XP SP3 and 2003 through 8.1 and 2012. A native 64 bit build of Cygwin has also been available since mid-2013. If your platform will run both and you are not sure which to choose, the 64 bit version is likely to be faster. Since Cygwin is a community-supported free software project, patches to provide support for other versions would be thoughtfully considered. Paid support contracts or enhancements are available through Red Hat. For information about getting a Red Hat support contract, see http://cygwin.com/license.html.

Keep in mind that Cygwin can only do as much as the underlying OS supports. Because of this, Cygwin will behave differently, and exhibit different limitations, on the various versions of Windows.

1.3. Where can I get it?
The home page for the Cygwin project is http://cygwin.com/. There you should find everything you need for Cygwin, including links for download and setup, a current list of mirror sites, a User's Guide, an API Reference, mailing lists and archives, and additional ported software.

You can find documentation for the individual GNU tools at http://www.gnu.org/manual/. (You should read GNU manuals from a local mirror. Check http://www.gnu.org/server/list-mirrors.html for a list of them.)

1.4. Is it free software?
Yes. Parts are GNU software (gcc, gas, ld, etc...), parts are covered by the standard X11 license, some of it is public domain, some of it was written by Cygnus and placed under the GPL. None of it is shareware. You don't have to pay anyone to use it but you should be sure to read the copyright section of the FAQ for more information on how the GNU General Public License may affect your use of these tools.

In particular, if you intend to port a proprietary (non-GPL'd) application using Cygwin, you will need the proprietary-use license for the Cygwin library. This is available for purchase; please visit http://cygwin.com/license.html for more information. All other questions should be sent to the project mailing list cygwin@cygwin.com.

Note that when we say "free" we mean freedom, not price. The goal of such freedom is that the people who use a given piece of software should be able to change it to fit their needs, learn from it, share it with their friends, etc. The Cygwin license allows you those freedoms, so it is free software.

1.5. What version of Cygwin is this, anyway?
To find the version of the installed Cygwin DLL, you can use   as on Linux, or  . Refer to each command's  output and the Cygwin User's Guide for more information.

If you are looking for the version number for the whole Cygwin release, there is none. Each package in the Cygwin release has its own version. The packages in Cygwin are continually improving, thanks to the efforts of net volunteers who maintain the Cygwin binary ports. Each package has its own version numbers and its own release process.

So, how do you get the most up-to-date version of Cygwin? Easy. Just download the Cygwin Setup program at http://cygwin.com/setup.exe. This program will handle the task of updating the packages on your system to the latest version. For more information about using Cygwin's setup.exe, see Setting Up Cygwin in the Cygwin User's Guide.

1.6. Who's behind the project?
(Please note that if you have cygwin-specific questions, all of these people will appreciate it if you use the cygwin mailing lists rather than sending personal email.)

Chris Faylor is behind many of the recent changes in Cygwin. Prior to joining Cygnus, he contributed significant fixes to the process control and environ code, reworked the strace mechanism, and rewrote the signal-related code from scratch as a Net contributor. In addition to continuing to make technical contributions, Chris is also currently the group's manager.

Corinna Vinschen has contributed several useful fixes to the path handling code, console support, improved security handling, and raw device support. Corinna is currently employed by Red Hat as a GDB/Cygwin engineer.

DJ Delorie has done important work in profiling Cygwin, worked on the Dejagnu automated testing framework, merged the dlltool functionality into ld, wrote a good deal of the Cygwin Users' Guide, authored the cygcheck utility, and made automated snapshots available from our project WWW page. DJ is currently employed by Red Hat as a GCC engineer.

Egor Duda has contributed many useful fixes. He is responsible for Cygwin's ability to start a debugger on detection of a fatal error as well as produce core dumps.

Robert Collins has contributed many improvements to thread handling as well as generic fixes to cygwin itself.

Kazuhiro Fujieda has contributed many bug fixes and bug reports.

Earnie Boyd has contributed many bug fixes and is the mingw and w32api maintainer.

David Starks-Browning is our dedicated FAQ maintainer.

Geoffrey Noer took over the Cygwin project from its initial author Steve Chamberlain in mid-1996. As maintainer, he produced Net releases beta 16 through 20; made the development snapshots; worked with Net contributors to fix bugs; made many various code improvements himself; wrote a paper on Cygwin for the 1998 Usenix NT Symposium; authored the project WWW pages, FAQ, README; etc. Geoffrey is not currently employed by Red Hat.

Steve Chamberlain designed and implemented Cygwin in 1995-1996 while working for Cygnus. He worked with the Net to improve the technology, ported/integrated many of the user tools for the first time to Cygwin, and produced all of the releases up to beta 14. Steve is not currently employed by Red Hat.

Marco Fuykschot and Peter Boncz of Data Distilleries contributed nearly all of the changes required to make Cygwin thread-safe. They also provided the pthreads interface.

Sergey Okhapkin has been an invaluable Net contributor. He implemented the tty/pty support, has played a significant role in revamping signal and exception handling, and has made countless contributions throughout the library. He also provided binaries of the development snapshots to the Net after the beta 19 release.

Mumit Khan has been most helpful on the EGCS end of things, providing quite a large number of stabilizing patches to the compiler tools for the B20 release.

Philippe Giacinti contributed the implementation of dlopen, dlclose, dlsym, dlfork, and dlerror in Cygwin.

Ian Lance Taylor did a much-needed rework of the path handling code for beta 18, and has made many assorted fixes throughout the code. Jeremy Allison made significant contributions in the area of file handling and process control, and rewrote select from scratch. Doug Evans rewrote the path-handling code in beta 16, among other things. Kim Knuttila and Michael Meissner put in many long hours working on the now-defunct PowerPC port. Jason Molenda and Mark Eichin have also made important contributions.

Please note that all of us working on Cygwin try to be as responsive as possible and deal with patches and questions as we get them, but realistically we don't have time to answer all of the email that is sent to the main mailing list. Making Net releases of the Win32 tools and helping people on the Net out is not our primary job function, so some email will have to go unanswered.

Many thanks to everyone using the tools for their many contributions in the form of advice, bug reports, and code fixes. Keep them coming!

2.1. What is the recommended installation procedure?
There is only one recommended way to install Cygwin, which is to use the GUI installer "Cygwin Setup". It is flexible and easy to use. You can pick and choose the packages you wish to install, and update them individually. Full source code is available for all packages and tools. More information on using Cygwin Setup may be found at http://cygwin.com/cygwin-ug-net/setup-net.html.

If you do it any other way, you're on your own! That said, keep in mind that the GUI installer is a "work in progress", so there might be a few difficulties, especially if you are behind a firewall or have other specific requirements. If something doesn't work right for you, and it's not covered here or in the latest development snapshot at http://cygwin.com/snapshots/, then by all means report it to the mailing list.

The "Cygwin Setup" tool is most useful for installing Cygwin on a PC with direct access to the Internet. For machines without an internet connection, a tool such as pmcyg can be used to create a self-contained installer on CD or DVD including a user-defined collection of Cygwin packages.

For a searchable list of packages that can be installed with Cygwin, see http://cygwin.com/packages/.

2.2. What about an automated Cygwin installation?
The Cygwin Setup program is designed to be interactive, but there are a few different ways to automate it. If you are deploying to multiple systems, the best way is to run through a full installation once, saving the entire downloaded package tree. Then, on target systems, run setup.exe as a "Local Install" pointed at your downloaded package tree. You could do this non-interactively with the command line options setup.exe -q -L -l x:\cygwin-local\ , where your downloaded package tree is in x:\cygwin-local\ (see the next FAQ for an explanation of those options.)

For other options, search the mailing lists with terms such as cygwin automated setup or automated cygwin install.

2.3. Does setup.exe accept command-line arguments?
Yes, the full listing is written to the setup.log file when you run setup.exe --help. The current options are:

Command Line Options: -D --download                         Download from internet -L --local-install                    Install from local directory -s --site                             Download site -R --root                             Root installation directory -q --quiet-mode                       Unattended setup mode -h --help                             print help -l --local-package-dir                Local package directory -r --no-replaceonreboot               Disable replacing in-use files on next reboot. -n --no-shortcuts                     Disable creation of desktop and start menu shortcuts -N --no-startmenu                     Disable creation of start menu shortcut -d --no-desktop                       Disable creation of desktop shortcut -A --disable-buggy-antivirus          Disable known or suspected buggy anti virus software packages during execution.

2.4. Why not install in C:\?
The Cygwin Setup program will prompt you for a "root" directory. The default is C:\cygwin, but you can change it. You are urged not to choose something like C:\ (the root directory on the system drive) for your Cygwin root. If you do, then critical Cygwin system directories like etc, lib and bin could easily be corrupted by other (non-Cygwin) applications or packages that use \etc, \lib or \bin. Perhaps there is no conflict now, but who knows what you might install in the future? It's also just good common sense to segregate your Cygwin "filesystems" from the rest of your Windows system disk.

(In the past, there had been genuine bugs that would cause problems for people who installed in C:\, but we believe those are gone now.)

The suggestion C:\Program Files\Common Files\cygwin\ is not ideal as a substitute directory. Anything in a program files folder is intended to be read-only for normal users, once an administrator has installed the application. But Cygwin users need to write data in various folders within the Cygwin installation. Cygwin is one of several well known applications that do not have to go in Program Files, and do not follow the Windows tradition of scattering precious data, configuration data, and temporary or cache data into a particular operating system instance's registry and various obscure document or application data folders belonging to individual users or All Users of that operating system instance. Such applications are best kept separate in a prominent location outside any Windows hierarchy. One advantage is that you do not then need to install two copies in a dual boot system. The drive letters are swapped when you boot the other system, but you can make D:\cygwin appear as C:\cygwin by creating an NTFS junction. If you have backup policies for Windows system, configuration, applications, and user home directories, remember to adapt them to take care of the corresponding parts of applications like Cygwin.

2.5. Can I use Cygwin Setup to get old versions of packages (like gcc-2.95)?
Cygwin Setup can be used to install any packages that are on a Cygwin mirror, which usually includes one version previous to the current one. The complete list may be searched at http://cygwin.com/packages/. There is no complete archive of older packages. If you have a problem with the current version of a Cygwin package, please report it to the mailing list using the guidelines at http://cygwin.com/problems.html.

That said, if you really need an older package, you may be able to find an outdated or archival mirror by searching the web for an old package version (for example, gcc2-2.95.3-10-src.tar.bz2), but keep in mind that this older version will not be supported by the mailing list and that installing the older version will not help improve Cygwin.

2.6. Is Cygwin Setup, or one of the packages, infected with a virus?
Unlikely. Unless you can confirm it, please don't report it to the mailing list. Anti-virus products have been known to detect false positives when extracting compressed tar archives. If this causes problems for you, consider disabling your anti-virus software when running setup. Read the next entry for a fairly safe way to do this.

2.7. My computer hangs when I run Cygwin Setup!
Both Network Associates (formerly McAfee) and Norton anti-virus products have been reported to "hang" when extracting Cygwin tar archives. If this happens to you, consider disabling your anti-virus software when running Cygwin Setup. The following procedure should be a fairly safe way to do that:


 * Download setup.exe and scan it explicitly.
 * Turn off the anti-virus software.
 * Run setup to download and extract all the tar files.
 * Re-activate your anti-virus software and scan everything in C:\cygwin (or wherever you chose to install), or your entire hard disk if you are paranoid.

This should be safe, but only if Cygwin Setup is not substituted by something malicious, and no mirror has been compromised.

See also http://cygwin.com/faq/faq.using.html#faq.using.bloda for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin.

2.8. What packages should I download? Where are 'make', 'gcc', 'vi', etc?
When using Cygwin Setup for the first time, the default is to install a minimal subset of all available packages. If you want anything beyond that, you will have to select it explicitly. See http://cygwin.com/packages/ for a searchable list of available packages, or use cygcheck -p as described in the Cygwin User's Guide at http://cygwin.com/cygwin-ug-net/using-utils.html#cygcheck.

If you want to build programs, of course you'll need gcc, binutils, make and probably other packages from the "Devel'' category. Text editors can be found under ``Editors". ''

2.9. How do I just get everything?
Long ago, the default was to install everything, much to the irritation of most users. Now the default is to install only a basic core of packages. Cygwin Setup is designed to make it easy to browse categories and select what you want to install or omit from those categories. It's also easy to install everything:


 * At the "Select Packages screen, in ``Categories view, at the line marked ``All, click on the word ``default so that it changes to ``install". (Be patient, there is some computing to do at this step. It may take a second or two to register the change.) This tells Setup to install everything, not just what it thinks you should have by default.
 * Now click on the "View button (twice) until you get the ``Partial" view. This shows exactly which packages are about to be downloaded and installed. 

This procedure only works for packages that are currently available. There is no way to tell Cygwin Setup to install all packages by default from now on. As new packages become available that would not be installed by default, you have to repeat the above procedure to get them.

In general, a better method (in my opinion), is to:


 * First download & install all packages that would normally be installed by default. This includes fundamental packages and any updates to what you have already installed. Then...
 * Run Cygwin Setup again, and apply the above technique to get all new packages that would not be installed by default. You can check the list in the Partial View before proceeding, in case there's something you really don't want.

In the latest version of Cygwin Setup, if you click the "View" button (twice) more, it shows packages not currently installed. You ought to check whether you really want to install everything!

2.10. How much disk space does Cygwin require?
That depends, obviously, on what you've chosen to download and install. A full installation today is probably larger than 800MB installed, not including the package archives themselves nor the source code.

After installation, the package archives remain in your "Local Package Directory", by default the location of setup.exe. You may conserve disk space by deleting the subdirectories there. These directories will have very weird looking names, being encoded with their URLs (named ftp%3a%2f...).

Of course, you can keep them around in case you want to reinstall a package. If you want to clean out only the outdated packages, Michael Chase has written a script called clean_setup.pl, available at http://home.ix.netcom.com/~mchase/zip/.

2.11. How do I know which version I upgraded from?
Detailed logs of the most recent Cygwin Setup session can be found in /var/log/setup.log.full and less verbose information about prior actions is in /var/log/setup.log.

2.12. What if setup fails?
First, make sure that you are using the latest version of Cygwin Setup. The latest version is always available from the 'Install Cygwin now' link on the Cygwin Home Page at http://cygwin.com/.

If you are downloading from the Internet, setup will fail if it cannot download the list of mirrors at http://cygwin.com/mirrors.html. It could be that the network is too busy. Something similar could be the cause of a download site not working. Try another mirror, or try again later.

If setup refuses to download a package that you know needs to be upgraded, try deleting that package's entry from /etc/setup. If you are reacting quickly to an announcement on the mailing list, it could be that the mirror you are using doesn't have the latest copy yet. Try another mirror, or try again tomorrow.

If setup has otherwise behaved strangely, check the files setup.log and setup.log.full in /var/log (C:\cygwin\var\log by default). It may provide some clues as to what went wrong and why.

If you're still baffled, search the Cygwin mailing list for clues. Others may have the same problem, and a solution may be posted there. If that search proves fruitless, send a query to the Cygwin mailing list. You must provide complete details in your query: version of setup, options you selected, contents of setup.log and setup.log.full, what happened that wasn't supposed to happen, etc.

2.13. My Windows logon name has a space in it, will this cause problems?
Most definitely yes! UNIX shells (and thus Cygwin) use the space character as a word delimiter. Under certain circumstances, it is possible to get around this with various shell quoting mechanisms, but you are much better off if you can avoid the problem entirely.

On Windows NT/2000/XP you have two choices:


 * You can rename the user in the Windows User Manager GUI and then run mkpasswd.
 * You can simply edit the /etc/passwd file and change the Cygwin user name (first field). It's also a good idea to avoid spaces in the home directory.

On Windows 95/98/ME you can create a new user and run mkpasswd, or you can delete the offending entry from /etc/passwd. Cygwin will then use the name in the default entry with uid 500.

2.14. My HOME environment variable is not what I want.
When starting Cygwin from Windows, HOME is determined as follows in order of decreasing priority:


 * HOME from the Windows environment, translated to POSIX form.
 * The entry in /etc/passwd
 * HOMEDRIVE and HOMEPATH from the Windows environment

When using Cygwin from the network (telnet, ssh,...), HOME is set from /etc/passwd.

If your HOME is set to a value such as /cygdrive/c, it is likely that it was set in Windows. Start a DOS Command Window and type "set HOME" to verify if this is the case.

Access to shared drives is often restricted when starting from the network, thus Domain users may wish to have a different HOME in the Windows environment (on shared drive) than in /etc/passwd (on local drive). Note that ssh only considers /etc/passwd, disregarding HOME.

2.15. How do I uninstall individual packages?
Run Cygwin Setup as you would to install packages. In the list of packages to install, browse the relevant category or click on the "View" button to get a full listing. Click on the cycle glyph until the action reads "Uninstall". Proceed by clicking "Next".

2.16. How do I uninstall a Cygwin service?
List all services you have installed with cygrunsrv -L. If you do not have cygrunsrv installed, skip this FAQ.

Before removing the service, you should stop it with cygrunsrv --stop service_name. If you have inetd configured to run as a standalone service, it will not show up in the list, but cygrunsrv --stop inetd will work to stop it as well.

Lastly, remove the service with cygrunsrv --remove service_name.

2.17. How do I uninstall all of Cygwin?
Setup has no automatic uninstall facility. The recommended method to remove all of Cygwin is as follows:

If you have any Cygwin services running, remove by repeating the instructions in http://cygwin.com/faq/faq.setup.html#faq.setup.uninstall-service for all services that you installed. Common services that might have been installed are sshd, cron, cygserver, inetd, apache, postgresql, and so on.

Stop the X11 server if it is running, and terminate any Cygwin programs that might be running in the background. Remove all mount information by typing umount -A and then exit the command prompt and ensure that no Cygwin processes remain. Note: If you want to save your mount points for a later reinstall, first save the output of mount -m as described at http://cygwin.com/cygwin-ug-net/using-utils.html#mount.

Delete the Cygwin root folder and all subfolders. If you get an error that an object is in use, then ensure that you've stopped all services and closed all Cygwin programs. If you get a 'Permission Denied' error then you will need to modify the permissions and/or ownership of the files or folders that are causing the error. For example, sometimes files used by system services end up owned by the SYSTEM account and not writable by regular users.

The quickest way to delete the entire tree if you run into this problem is to change the ownership of all files and folders to your account. To do this in Windows Explorer, right click on the root Cygwin folder, choose Properties, then the Security tab. If you are using Windows XP Home or Simple File Sharing, you will need to boot into Safe Mode to access the Security tab. Select Advanced, then go to the Owner tab and make sure your account is listed as the owner. Select the 'Replace owner on subcontainers and objects' checkbox and press Ok. After Explorer applies the changes you should be able to delete the entire tree in one operation. Note that you can also achieve this in Cygwin by typing chown -R user / or by using other tools such as CACLS.EXE.

Delete the Cygwin shortcuts on the Desktop and Start Menu, and anything left by setup.exe in the download directory. However, if you plan to reinstall Cygwin it's a good idea to keep your setup.exe download directory since you can reinstall the packages left in its cache without redownloading them.

If you added Cygwin to your system path, you should remove it unless you plan to reinstall Cygwin to the same location. Similarly, if you set your CYGWIN environment variable system-wide and don't plan to reinstall, you should remove it.

Finally, if you want to be thorough you can delete the registry tree Software\Cygnus Solutions under HKEY_LOCAL_MACHINE and/or HKEY_CURRENT_USER. However, if you followed the directions above you will have already removed all the mount information which is typically the only thing stored in the registry.

2.18. How do I install snapshots?
First, are you sure you want to do this? Snapshots are risky. They have not been tested. Use them only if there is a feature or bugfix that you need to try, and you are willing to deal with any problems, or at the request of a Cygwin developer.

You should generally install the full cygwin-inst-YYYYMMDD.tar.bz2 update, rather than just the DLL, otherwise some components may be out of sync.

You cannot use Cygwin Setup to install a snapshot.

First, you will need to download the snapshot from the snapshots page at http://cygwin.com/snapshots/. Note the directory where you saved the snapshot tarball.

Before installing a snapshot, you must first Close all Cygwin applications, including shells and services (e.g., inetd, sshd). You will not be able to replace cygwin1.dll if any Cygwin process is running. You may have to restart Windows to clear the DLL from memory (beware of automatic service startup).

Most of the downloaded snapshot can be installed using tar. Cygwin tar won't be able to update /usr/bin/cygwin1.dll (because it's used by tar itself), but it should succeed with everything else. If you are only installing the DLL snapshot, skip the first tar command. Open a bash shell (it should be the only running Cygwin process) and issue the following commands:

/bin/tar -C/ -jxvf /posix/path/to/cygwin-inst-YYYYMMDD.tar.bz2 --exclude=usr/bin/cygwin1.dll /bin/tar -C/tmp -jxvf /posix/path/to/cygwin-inst-YYYYMMDD.tar.bz2 usr/bin/cygwin1.dll

Exit the bash shell, and use Explorer or the Windows command shell to first rename C:\cygwin\bin\cygwin1.dll to C:\cygwin\bin\cygwin1-prev.dll and then move C:\cygwin\tmp\usr\bin\cygwin1.dll to C:\cygwin\bin\cygwin1.dll (assuming you installed Cygwin in C:\cygwin).

The operative word in trying the snapshots is "trying". If you notice a problem with the snapshot that was not present in the release DLL (what we call a "regression"), please report it to the Cygwin mailing list (see http://cygwin.com/problems.html for problem reporting guidelines). If you wish to go back to the older version of the DLL, again, close all Cygwin processes, delete C:\cygwin\bin\cygwin1.dll, and rename C:\cygwin\bin\cygwin1-prev.dll back to C:\cygwin\bin\cygwin1.dll (again assuming that your "/" is C:\cygwin). To restore the rest of the snapshot files, reinstall the "cygwin" package using Setup.

2.19. Can Cygwin Setup maintain a "mirror"?
NO. Cygwin Setup cannot do this for you. Use a tool designed for this purpose. See http://rsync.samba.org/, http://wget.sunsite.dk/ for utilities that can do this for you. For more information on setting up a custom Cygwin package server, see the Cygwin Setup homepage at http://sources.redhat.com/cygwin-apps/setup.html.

2.20. How can I make my own portable Cygwin on CD?
Some users have successfully done this, for example Indiana University's XLiveCD http://xlivecd.indiana.edu/, and there is now a specialized application (pmcyg) which can automate most of the process. Full instructions for constructing a porttable Cygwin on CD by hand can be found on the mailing list at http://www.cygwin.com/ml/cygwin/2003-07/msg01117.html. (Thanks to fergus at bonhard dot uklinux dot net for these instructions.)

2.21. How do I save, restore, delete, or modify the Cygwin information stored in the registry?
Currently Cygwin stores its mount table information in the registry. It is recommended that you use the mount and umount commands to manipulate the mount information instead of directly modifying the registry.

To save the mount information to a file for later restoration, use mount -m > mounts.bat To remove all mount information use umount -A. To reincorporate saved mount information just run the batch file. For more information on using mount, see http://cygwin.com/cygwin-ug-net/using-utils.html#mount.

3.1. Where's the documentation?
If you have installed Cygwin, you can find lots of documentation in /usr/share/doc/. Some packages have Cygwin specific instructions in a file /usr/share/doc/Cygwin/package_name.README. In addition, many packages ship with standard documentation, which you can find in /usr/share/doc/package_name or by using the man or info tools. (Hint: use cygcheck -l package_name to list what man pages the package includes.) Some older packages still keep their documentation in /usr/doc/ instead of /usr/share/doc/.

There are links to quite a lot of documentation on the main Cygwin project web page, http://cygwin.com/, including this FAQ. Be sure to at least read any 'Release Notes' or 'Readme' or 'read this' links on the main web page, if there are any.

There is a comprehensive Cygwin User's Guide at http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html and an API Reference at http://cygwin.com/cygwin-api/cygwin-api.html.

You can find documentation for the individual GNU tools at http://www.fsf.org/manual/. (You should read GNU manuals from a local mirror, check http://www.fsf.org/server/list-mirrors.html for a list of them.)

3.2. What Cygwin mailing lists can I join?
Comprehensive information about the Cygwin mailing lists can be found at http://cygwin.com/lists.html.

3.3. What if I have a problem? (Or: Why won't you/the mailing list answer my questions?)
Comprehensive information about reporting problems with Cygwin can be found at http://cygwin.com/problems.html.

4.1. Why can't my application locate cygncurses5.dll? or cygintl.dll? or cygreadline5.dll? or ...?
If you upgraded recently, and suddenly vim (or some other Cygwin application) cannot find cygncurses5.dll, it probably means that you did not follow these instructions properly: http://cygwin.com/ml/cygwin-announce/2001/msg00124.html. To repair the damage, you must run Cygwin Setup again, and re-install the libncurses5 package.

Note that Cygwin Setup won't show this option by default. In the "Select packages to install" dialog, click on the Full/Part button. This lists all packages, even those that are already installed. Scroll down to locate the libncurses5 package. Click on the "cycle" glyph until it says "Reinstall". Continue with the installation.

Similarly, if something cannot find cygintl.dll, then run Cygwin Setup and re-install the libintl and libintl1 packages.

For a detailed explanation of the general problem, and how to extend it to other missing DLLs (like cygreadline5.dll) and identify their containing packages, see http://cygwin.com/ml/cygwin/2002-01/msg01619.html.

4.2. Why is Cygwin suddenly so slow?
If you recently upgraded and suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. This now means the network share c, which will slow things down tremendously if it does not exist.

Using //c (for C:) doesn't work anymore. (Similarly for any drive letter, e.g. //z for Z:) This "feature" has long been deprecated, and no longer works at all in the latest release. As of release 1.3.3, //c now means the network share c. For a detailed discussion of why this change was made, and how deal with it now, refer to http://sources.redhat.com/ml/cygwin/2001-09/msg00014.html.

4.3. Why don't my services work?
Most Windows services run as a special user called SYSTEM. If you installed Cygwin for "Just Me", the SYSTEM user won't see your Cygwin mount table. You need to re-mount all of your mounts as "system" for services to work. You can re-run setup.exe and select "Install for All Users", or this script will do the trick:

eval "`mount -m | sed -e 's/ -u / -s /g' -e 's/$/;/'`"

4.4. Why can't my services access network shares?
When a service switches to a certain user, it is running as SYSTEM impersonating the user account. During impersonation, the user's password is not available and so non-public network shares are not available. For more information, see http://cygwin.com/cygwin-ug-net/ntsec.html.

Workarounds include using public network share that does not require authentication (for non-critical files), providing your password to a net use command, or running the service as your own user with cygrunsrv -u (see /usr/share/doc/Cygwin/cygrunsrv.README for more information).

4.5. How should I set my PATH?
This is done for you in the file /etc/profile, which is sourced by bash when you start it from the Desktop or Start Menu shortcut, created by setup.exe. The line is

PATH="/usr/local/bin:/usr/bin:/bin:$PATH"

Effectively, this prepends /usr/local/bin and /usr/bin to your Windows system path. If you choose to reset your PATH, say in $HOME/.bashrc, or by editing etc/profile directly, then you should follow this rule. You must have /usr/bin in your PATH before any Windows system directories. (And you must not omit the Windows system directories!) Otherwise you will likely encounter all sorts of problems running Cygwin applications.

4.6. Bash says "command not found", but it's right there!
If you compile a program, you might find that you can't run it:

bash$ gcc -o hello hello.c       bash$ hello bash: hello: command not found

Unlike Windows, bash does not look for programs in. (the current directory) by default. You can add. to your PATH (see above), but this is not recommended (at least on UNIX) for security reasons. Just tell bash where to find it, when you type it on the command line:

bash$ gcc -o hello hello.c       bash$ ./hello Hello World!

4.7. How do I convert between Windows and UNIX paths?
Use the 'cygpath' utility. Type 'cygpath --help' for information. For example (on my installation):

bash$ cygpath --windows ~/.bashrc D:\starksb\.bashrc bash$ cygpath --unix C:/cygwin/bin/cygwin.bat /usr/bin/cygwin.bat bash$ cygpath --unix C:\\cygwin\\bin\\cygwin.bat /usr/bin/cygwin.bat

Note that bash interprets the backslash '\' as an escape character, so you must type it twice in the bash shell if you want it to be recognized as such.

4.8. Why doesn't bash read my .bashrc file on startup?
Your .bashrc is read from your home directory specified by the HOME environment variable. It uses /.bashrc if HOME is not set. So you need to set HOME correctly, or move your .bashrc to the top of the drive mounted as / in Cygwin.

4.9. How can I get bash filename completion to be case insensitive?
Add the following to your ~/.bashrc file:

shopt -s nocaseglob

and add the following to your ~/.inputrc file:

set completion-ignore-case on

4.10. Can I use paths/filenames containing spaces in them?
Cygwin does support spaces in filenames and paths. That said, some utilities that use the library may not, since files don't typically contain spaces in Unix. If you stumble into problems with this, you will need to either fix the utilities or stop using spaces in filenames used by Cygwin tools.

In particular, bash interprets space as a word separator. You would have to quote a filename containing spaces, or escape the space character. For example:

bash-2.03$ cd '/cygdrive/c/Program Files'

or

bash-2.03$ cd /cygdrive/c/Program\ Files

4.11. Why can't I cd into a shortcut to a directory?
Cygwin versions < 1.3.0 do not follow MS Windows Explorer Shortcuts (*.lnk files). It sees a shortcut as a regular file and this you cannot "cd" into it.

Since version 1.3.0, Cygwin uses shortcuts as symlinks by default.

Cygwin shortcuts are different from shortcuts created by native Windows applications. Windows applications can usually make use of Cygwin shortcuts but not vice versa. This is by choice. The reason is that Windows shortcuts may contain a bunch of extra information which would get lost, if, for example, Cygwin tar archives and extracts them as symlinks.

Changing a Cygwin shortcut in Windows Explorer usually changes a Cygwin shortcut into a Windows native shortcut. Afterwards, Cygwin will not recognize it as symlink anymore.

4.12. I'm having basic problems with find. Why?
Make sure you are using the find that came with Cygwin and that you aren't picking up the Win32 find command instead. You can verify that you are getting the right one by doing a "type find" in bash.

If the path argument to find, including current directory (default), is itself a symbolic link, then find will not traverse it unless you specify the -follow option. This behavior is different than most other UNIX implementations, but is not likely to change.

If find does not seem to be producing enough results, or seems to be missing out some directories, you may be experiencing a problem with one of find's optimisations. The absence of. and .. directories on some filesystems, such as DVD-R UDF, can confuse find. See the documentation for the option -noleaf in the man page.

4.13. Why doesn't su work?
The su command has been in and out of Cygwin distributions, but it has not been ported to Cygwin and has never worked. It is currently installed as part of the sh-utils, but again, it does not work.

You may be able to use login instead, but you should read http://www.cygwin.com/ml/cygwin/2001-03/msg00337.html first.

For some technical background into why su doesn't work, read http://www.cygwin.com/ml/cygwin/2003-06/msg00897.html and related messages.

4.14. Why doesn't man (or apropos) work?
Before you can use man -k or apropos, you must create the whatis database. Just run the command

/usr/sbin/makewhatis

(it may take a minute to complete).

4.15. Why doesn't chmod work?
The most common case is that your /etc/passwd or /etc/group files are not properly set up. If ls -l shows a group of mkpasswd or mkgroup, you need to run one or both of those commands.

If you're using FAT32 instead of NTFS, chmod will fail since FAT32 does not provide any security. You might consider converting the drive to NTFS with CONVERT.EXE.

For other cases, understand that Cygwin attempts to show UNIX permissions based on the security features of Windows, so the Windows ACLs are likely the source of your problem. See the Cygwin User's Guide at http://cygwin.com/cygwin-ug-net/ntsec.html for more information on how Cygwin maps Windows permissions.

4.16. Why doesn't mkdir -p work on a network share?
Starting with coreutils-5.3.0-6 and cygwin-1.5.17, you can do something like this:

bash$ mkdir -p //MACHINE/Share/path/to/new/dir

However, coreutils expects Unix path names, so something like mkdir -p \\\\machine\\share\\path will fail.

4.17. Why doesn't my shell script work?
There are two basic problems you might run into. One is the fact that /bin/sh is really bash (prior to bash-3.0-6, /bin/sh was ash). and is missing some features you might expect in /bin/sh, particularly if you are used to /bin/sh actually being zsh (MacOS X "Panther") or ksh (Tru64).

Or, it could be a permission problem, and Cygwin doesn't understand that your script is executable. Because chmod may not work (see FAQ entry above), Cygwin must read the contents of files to determine if they are executable. If your script does not start with

#! /bin/sh

(or any path to a script interpreter, it does not have to be /bin/sh) then Cygwin will not know it is an executable script. The Bourne shell idiom



also works.

Note that you can use mount -x to force Cygwin to treat all files under the mount point as executable. This can be used for individual files as well as directories. Then Cygwin will not bother to read files to determine whether they are executable.

4.18. How do I print under Cygwin?
There is no working lp or lpr system as you would find on UNIX.

Jason Tishler has written a couple of messages that explain how to use a2ps (for nicely formatted text in PostScript) and ghostscript (to print PostScript files on non-PostScript Windows printers). Start at http://cygwin.com/ml/cygwin/2001-04/msg00657.html. Note that the file command is now available as part of Cygwin setup.

Alternatively, on NT, you can use the Windows print command. (It does not seem to be available on Win9x.) Type

bash$ print /\?

for usage instructions (note the ? must be escaped from the shell).

Finally, you can simply cat the file to the printer's share name:

bash$ cat myfile > //host/printer

You may need to press the formfeed button on your printer or append the formfeed character to your file.

4.19. Why don't international (Unicode) characters work?
Internationalization is a complex issue. The short answer is that Cygwin is not Unicode-aware, so things that might work in Linux will not necessarily work on Cygwin. However, some things do work. To type international characters (?ao) in bash, add the following lines to your ~/.inputrc file and restart bash:

set meta-flag on        set convert-meta off set output-meta on        set input-meta on        set kanji-code sjis

These are options to the readline library, which you can read about in the bash(1) and readline(3) man pages. Other tools that do not use readline for display, such as less and ls, require additional settings, which could be put in your ~/.bashrc:

alias less='/bin/less -r' alias ls='/bin/ls -F --color=tty --show-control-chars' export LANG="ja_JP.SJIS" export OUTPUT_CHARSET="sjis"

These examples use the Japanese Shift-JIS character set, obviously you will want to change them for your own locale.

4.20. Why don't cursor keys work under Win95/Win98?
(Please note: This section has not yet been updated for the latest net release.) Careful examination shows that they not just non-functional, but rather behave strangely, for example, with NumLock off, keys on numeric keyboard work, until you press usual cursor keys, when even numeric stop working, but they start working again after hitting alphanumeric key, etc. This reported to happen on localized versions of Win98 and Win95, and not specific to Cygwin; there are known cases of Alt+Enter (fullscreen/windowed toggle) not working and shifts sticking with other programs. The cause of this problem is Microsoft keyboard localizer which by default installed in 'autoexec.bat'. Corresponding line looks like:

keyb ru,,C:\WINDOWS\COMMAND\keybrd3.sys

(That's for russian locale.) You should comment that line if you want your keys working properly. Of course, this will deprive you of your local alphabet keyboard support, so you should think about another localizer. ex-USSR users are of course knowledgeable of Keyrus localizer, and it might work for other locales too, since it has keyboard layout editor. But it has russian messages and documentation ;-( Reference URL is http://www.hnet.ru/software/contrib/Utils/KeyRus/ (note the you may need to turn off Windows logo for Keyrus to operate properly).

4.21. Is it OK to have multiple copies of the DLL?
You should only have one copy of the Cygwin DLL on your system. If you have multiple versions, they will conflict and cause problems.

If you get the error "shared region is corrupted" or "shared region version mismatch" it means you have multiple versions of cygwin1.dll running at the same time. This could happen, for example, if you update cygwin1.dll without exiting all Cygwin apps (including inetd) beforehand.

The only DLL that is sanctioned by the Cygwin project is the one that you get by running http://cygwin.com/setup.exe, installed in the directory controlled by this program. If you have other versions on your system and desire help from the cygwin project, you should delete or rename all DLLs that are not installed by setup.exe.

If you're trying to find multiple versions of the DLL that are causing this problem, reboot first, in case DLLs still loaded in memory are the cause. Then use the Windows System find utility to search your whole machine, not just components in your PATH (as 'type' would do) or cygwin-mounted filesystems (as Cygwin 'find' would do).

4.22. Why isn't package XYZ available in Cygwin?
Probably because there is nobody willing or able to maintain it. It takes time, and the priority for the Cygwin Team is the Cygwin package. The rest is a volunteer effort. Want to contribute? See http://cygwin.com/setup.html.

4.23. Why is the Cygwin package of XYZ so out of date?
(Also: Why is the version of package XYZ older than the version that I can download from the XYZ web site? Why is the version of package XYZ older than the version that I installed on my linux system? Is there something special about Cygwin which requires that only an older version of package XYZ will work on it?)

Every package in the Cygwin distribution has a maintainer who is responsible for sending out updates of the package. This person is a volunteer who is rarely the same person as the official developer of the package. If you notice that a version of a package seems to be out of date, the reason is usually pretty simple -- the person who is maintaining the package hasn't gotten around to updating it yet. Rarely, the newer package actually requires complex changes that the maintainer is working out.

If you urgently need an update, sending a polite message to the cygwin mailing list pinging the maintainer is perfectly acceptable. There are no guarantees that the maintainer will have time to update the package or that you'll receive a response to your request, however.

Remeber that the operative term here is "volunteer".

4.24. How can I access other drives?
You have some flexibility here.

Cygwin has a builtin "cygdrive prefix" for drives that are not mounted. You can access any drive, say Z:, as '/cygdrive/z/'.

In some applications (notably bash), you can use the familiar windows :/path/, using posix forward-slashes ('/') instead of Windows backward-slashes ('\'). (But see the warning below!) This maps in the obvious way to the Windows path, but will be converted internally to use the Cygwin path, following mounts (default or explicit). For example:

bash$ cd C:/Windows bash$ pwd /cygdrive/c/Windows

and

bash$ cd C:/cygwin bash$ pwd /

for a default setup. You could also use backward-slashes in the Windows path, but these would have to be escaped from the shell.

Warning: There is some ambiguity in going from a Windows path to the posix path, because different posix paths, through different mount points, could map to the same Windows directory. This matters because different mount points may be binmode or textmode, so the behavior of Cygwin apps will vary depending on the posix path used to get there.

You can avoid the ambiguity of Windows paths, and avoid typing "/cygdrive", by explicitly mounting drives to posix paths. For example:

bash$ mkdir /c bash$ mount c:/ /c bash$ ls /c

Then /cygdrive/c/Windows becomes /c/Windows which is a little less typing.

Note that you only need to mount drives once. The mapping is kept in the registry so mounts stay valid pretty much indefinitely. You can only get rid of them with umount, or the registry editor.

The '-b' option to mount mounts the mountpoint in binary mode ("binmode") where text and binary files are treated equivalently. This should only be necessary for badly ported Unix programs where binary flags are missing from open calls. It is also the setting for /, /usr/bin and /usr/lib in a default Cygwin installation. The default for new mounts is text mode ("textmode"), which is also the mode for all "cygdrive" mounts.

You can change the default cygdrive prefix and whether it is binmode or textmode using the mount command. For example,

bash$ mount -b --change-cygdrive-prefix cygdrive

will change all /cygdrive/... mounts to binmode.

4.25. How can I copy and paste into Cygwin console windows?
First, consider using rxvt instead of the standard console window. In rxvt, selecting with the left-mouse also copies, and middle-mouse pastes. It couldn't be easier!

Under Windows NT, open the properties dialog of the console window. The options contain a toggle button, named "Quick edit mode". It must be ON. Save the properties.

Under Windows 9x, open the properties dialog of the console window. Select the Misc tab. Uncheck Fast Pasting. Check QuickEdit.

You can also bind the insert key to paste from the clipboard by adding the following line to your .inputrc file:

"\e[2~": paste-from-clipboard

4.26. What firewall should I use with Cygwin?
We have had good reports about Kerio Personal Firewall, ZoneLabs Integrity Desktop, and the built-in firewall in Windows XP. Other well-known products including ZoneAlarm and Norton Internet Security have caused problems for some users but work fine for others. At last report, Agnitum Outpost did not work with Cygwin. If you are having strange connection-related problems, disabling the firewall is a good troubleshooting step (as is closing or disabling all other running applications, especially resource-intensive processes such as indexed search).

On the whole, Cygwin doesn't care which firewall is used. The few rare exceptions have to do with socket code. Cygwin uses sockets to implement many of its functions, such as IPC. Some overzealous firewalls install themselves deeply into the winsock stack (with the 'layered service provider' API) and install hooks throughout. Sadly the mailing list archives are littered with examples of poorly written firewall-type software that causes things to break. Note that with many of these products, simply disabling the firewall does not remove these changes; it must be completely uninstalled.

See also http://cygwin.com/faq/faq.using.html#faq.using.bloda for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin.

4.27. How can I share files between Unix and Windows?
During development, we have both Linux boxes running Samba and Windows machines. We often build with cross-compilers under Linux and copy binaries and source to the Windows system or just toy with them directly off the Samba-mounted partition. On dual-boot NT/Windows 9x machines, we usually use the FAT filesystem so we can also access the files under Windows 9x.

4.28. Is Cygwin case-sensitive? What are managed mounts?
Several Unix programs expect to be able to use to filenames spelled the same way, but with different case. A prime example of this is perl's configuration script, which wants Makefile and makefile. WIN32 can't tell the difference between files with just different case, so the configuration fails.

To help with this problem, starting in cygwin-1.5.0 it is possible to have a case sensitive Cygwin managed mount. This is an experimental feature and should be used with caution. You should only use it for directories that are initially unpopulated and are due to be completely managed by cygwin (hence the name). So, the best use would be to create an empty directory, mount it, and then add files to it:

mkdir /managed-dir mount -o managed c:/cygwin/managed-dir /managed-dir cd /managed-dir/ touch makefile touch Makefile

4.29. What about DOS special filenames?
Files cannot be named com1, lpt1, or aux (to name a few); either as the root filename or as the extension part. If you do, you'll have trouble. Unix programs don't avoid these names which can make things interesting. E.g., the perl distribution has a file called aux.sh. The perl configuration tries to make sure that aux.sh is there, but an operation on a file with the magic letters 'aux' in it will hang.

4.30. When it hangs, how do I get it back?
If something goes wrong and the tools hang on you for some reason (easy to do if you try and read a file called aux.sh), first try hitting ^C to return to bash or the cmd prompt.

If you start up another shell, and applications don't run, it's a good bet that the hung process is still running somewhere. Use the Task Manager, pview, or a similar utility to kill the process.

And, if all else fails, there's always the reset button/power switch. This should never be necessary under Windows NT.

4.31. Why the weird directory structure?

 * Why do /lib and /usr/lib (and /bin, /usr/bin) point to the same thing?
 * Why use mounts instead of symbolic links?
 * Can I use a disk root (e.g., C:\) as Cygwin root? Why is this discouraged?

After a new installation in the default location, your mount points will look something like this:

bash$ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode)

(Exactly what you see depends on what options you gave to setup.exe.)

Note that /bin and /usr/bin point to the same location, as do /lib and /usr/lib. This is intentional, and you should not undo these mounts unless you really know what you are doing.

Various applications and packages may expect to be installed in /lib or /usr/lib (similarly /bin or /usr/bin). Rather than distinguish between them and try to keep track of them (possibly requiring the occasional duplication or symbolic link), it was decided to maintain only one actual directory, with equivalent ways to access it.

Symbolic links had been considered for this purpose, but were dismissed because they do not always work on Samba drives. Also, mounts are faster to process because no disk access is required to resolve them.

Note that non-cygwin applications will not observe Cygwin mounts (or symlinks for that matter). For example, if you use WinZip to unpack the tar distribution of a Cygwin package, it may not get installed to the correct Cygwin path. So don't do this!

It is strongly recommended not to make the Cygwin root directory the same as your drive's root directory, unless you know what you are doing and are prepared to deal with the consequences. It is generally easier to maintain the Cygwin hierarchy if it is isolated from, say, C:\. For one thing, you avoid possible collisions with other (non-cygwin) applications that may create (for example) \bin and \lib directories. (Maybe you have nothing like that installed now, but who knows about things you might add in the future?)

4.32. How do anti-virus programs like Cygwin?
Users have reported that NAI (formerly McAfee) VirusScan for NT (and others?) is incompatible with Cygwin. This is because it tries to scan the newly loaded shared memory in cygwin1.dll, which can cause fork to fail, wreaking havoc on many of the tools. (It is not confirmed that this is still a problem, however.)

There have been several reports of NAI VirusScan causing the system to hang when unpacking tar.gz archives. This is surely a bug in VirusScan, and should be reported to NAI. The only workaround is to disable VirusScan when accessing these files. This can be an issue during setup, and is discussed in that FAQ entry.

Some users report a significant performance hit using Cygwin when their anti-virus software is enabled. Rather than disable the anti-virus software completely, it may be possible to specify directories whose contents are exempt from scanning. In a default installation, this would be C:\cygwin\bin. Obviously, this could be exploited by a hostile non-Cygwin program, so do this at your own risk.

See also http://cygwin.com/faq/faq.using.html#faq.using.bloda for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin.

4.33. Is there a Cygwin port of GNU Emacs?
Yes! It uses the X11 (http://cygwin.com/xfree/) Windows interface. From a remote login shell, this "emacs -nw" works fine. There is also a non-X11 version which just provides the text-only terminal interface. There is also emacs-w32 with a MS Windows interface. Use Cygwin Setup to install any of these, even more than one.

4.34. What about NT Emacs?
If you want a GNU Emacs with a native Microsoft Windows interface, but without X, then you can also use the native Windows port, commonly known as "NT Emacs". You get NT Emacs from any GNU mirror. It is not available from Cygwin Setup.

NT Emacs uses the Windows command shell by default. Since it is not a Cygwin application, it has no knowledge of Cygwin mounts. With those points in mind, you need to add the following code to your ~/.emacs (or ~/_emacs) file in order to use Cygwin bash. This is particularly useful for the JDEE package (http://jdee.sunsite.dk/). The following settings are for Emacs 21.1:

;; This assumes that Cygwin is installed in C:\cygwin (the       ;; default) and that C:\cygwin\bin is not already in your ;; Windows Path (it generally should not be). ;;       (setq exec-path (cons "C:/cygwin/bin" exec-path)) (setenv "PATH" (concat "C:\\cygwin\\bin;" (getenv "PATH"))) ;;       ;; NT-emacs assumes a Windows command shell, which you change ;; here. ;;       (setq shell-file-name "bash") (setenv "SHELL" shell-file-name) (setq explicit-shell-file-name shell-file-name) ;;       ;; This removes unsightly ^M characters that would otherwise ;; appear in the output of java applications. ;;       (add-hook 'comint-output-filter-functions                  'comint-strip-ctrl-m)

If you want NT Emacs to understand Cygwin paths, get cygwin-mount.el from http://www.emacswiki.org/elisp/index.html.

Note that all of this "just works" if you use the Cygwin port of Emacs from Cygwin Setup.

4.35. What about XEmacs?
For a concise description of the current situation with XEmacs, see this message from the Cygwin mailing list: http://cygwin.com/ml/cygwin/2002-11/msg00609.html.

If you want to use ftp from within XEmacs (for instance for updating the xemacs packages), you will want to install the Cygwin version of ftp (included in the inetutils package). Otherwise, xemacs (i.e. efs) will find the native windows ftp version and it is difficult to get this to work properly.

4.36. Is there a better alternative to the standard console window?
Yes! Use rxvt instead. It's an optional package in Cygwin Setup. You can use it with or without X11. You can resize it easily by dragging an edge or corner. Copy and paste is easy with the left and middle mouse buttons, respectively. It will honor settings in your ~/.Xdefaults file, even without X. For details see /usr/share/doc/Cygwin/rxvt- .README.

4.37. info error "dir: No such file or directory"
Cygwin packages install their info documentation in the /usr/share/info directory. But you need to create a dir file there before the standalone info program (probably /usr/bin/info) can be used to read those info files. This is how you do it:

bash$ cd /usr/share/info bash$ for f in *.info ; do install-info $f dir ; done

This may generate warnings:

install-info: warning: no info dir entry in `gzip.info' install-info: warning: no info dir entry in `time.info'

The install-info command cannot parse these files, so you will have to add their entries to /usr/share/info/dir by hand.

Even if the dir file already exists, you may have to update it when you install new Cygwin packages. Some packages update the dir file for you, but many don't.

4.38. Why do I get a message saying Out of Queue slots?
"Out of queue slots!" generally occurs when you're trying to remove many files that you do not have permission to remove (either because you don't have permission, they are opened exclusively, etc). What happens is Cygwin queues up these files with the supposition that it will be possible to delete these files in the future. Assuming that the permission of an affected file does change later on, the file will be deleted as requested. However, if too many requests come in to delete inaccessible files, the queue overflows and you get the message you're asking about. Usually you can remedy this with a quick chmod, close of a file, or other such thing. (Thanks to Larry Hall for this explanation).

4.39. Why don't symlinks work on samba-mounted filesystems?
Symlinks are marked with "system" file attribute. Samba does not enable this attribute by default. To enable it, consult your Samba documentation and then add these lines to your samba configuration file:

map system = yes create mask = 0775

Note that the 0775 can be anything as long as the 0010 bit is set.

4.40. Why does df report sizes incorrectly.
There is a bug in the Win32 API function GetFreeDiskSpace that makes it return incorrect values for disks larger than 2 GB in size. Perhaps that may be your problem?

4.41. Why doesn't Cygwin tcl/tk understand Cygwin paths?
The versions of Tcl/Tk distributed with Cygwin (e.g. cygtclsh80.exe, cygwish80.exe) are not actually "Cygwin versions" of those tools. They are built with the -mno-cygwin option to gcc, which means they do not understand Cygwin mounts or symbolic links.

See the entry "How do I convert between Windows and UNIX paths?" elsewhere in this FAQ.

4.42. What applications have been found to interfere with Cygwin?
From time to time, people have reported strange failures and problems in Cygwin and Cygwin packages that seem to have no rational explanation. Among the most common symptoms they report are fork failures, memory leaks, and file access denied problems. These problems, when they have been traced, often appear to be caused by interference from other software installed on the same PC. Security software, in particular, such as anti-virus, anti-spyware, and firewall applications, often implements its functions by installing hooks into various parts of the system, including both the Explorer shell and the underlying kernel. Sometimes these hooks are not implemented in an entirely transparent fashion, and cause changes in the behaviour which affect the operation of other programs, such as Cygwin.

Among the software that has been found to cause difficulties are:


 * Sonic Solutions burning software containing DLA component
 * Norton/MacAffee/Symantec antivirus or antispyware
 * Logitech webcam software with "Logitech process monitor" service
 * Kerio, Agnitum or ZoneAlarm Personal Firewall
 * Iolo System Mechanic/AntiVirus/Firewall
 * LanDesk
 * Windows Defender
 * Embassy Trust Suite fingerprint reader software wxvault.dll
 * NOD32 Antivirus
 * ByteMobile laptop optimization client

Sometimes these problems can be worked around, by temporarily or partially disabling the offending software. For instance, it may be possible to disable on-access scanning in your antivirus, or configure it to ignore files under the Cygwin installation root. Often, unfortunately, this is not possible; even disabling the software may not work, since many applications that hook the operating system leave their hooks installed when disabled, and simply set them into what is intended to be a completely transparent pass-through mode. Sometimes this pass-through is not as transparent as all that, and the hooks still interfere with Cygwin; in these cases, it may be necessary to uninstall the software altogether to restore normal operation.

Some of the symptoms you may experience are:


 * Random fork failures. Caused by hook DLLs that load themselves into every process in the system. POSIX fork semantics require that the memory map of the child process must be an exact duplicate of the parent process' layout. If one of these DLLs loads itself at a different base address in the child's memory space as compared to the address it was loaded at in the parent, it can end up taking the space that belonged to a different DLL in the parent. When Cygwin can't load the original DLL at that same address in the child, the fork call has to fail.


 * File access problems. Some programs (e.g., virus scanners with on-access scanning) scan or otherwise operate on every file accessed by all the other software running on your computer. In some cases they may retain an open handle on the file even after the software that is really using the file has closed it. This has been known to cause operations such as deletes, renames and moves to fail with access denied errors. In extreme cases it has been known for scanners to leak file handles, leading to kernel memory starvation.


 * Networking issues. Firewall software sometimes gets a bit funny about Cygwin. It's not currently understood why; Cygwin only uses the standard Winsock2 API, but perhaps in some less-commonly used fashion that doesn't get as well tested by the publishers of firewalls. Symptoms include mysterious failures to connect, or corruption of network data being sent or received.


 * Memory and/or handle leaks. Some applications that hook into the Windows operating system exhibit bugs when interacting with Cygwin that cause them to leak allocated memory or other system resources. Symptoms include complaints about out-of-memory errors and even virtual memory exhaustion dialog boxes from the O/S; it is often possible to see the excess memory allocation using a tool such as Task Manager or Sysinternals' Process Explorer, although interpreting the statistics they present is not always straightforward owing to complications such as virtual memory paging and file caching.

4.43. Can I install packages from within the cygwin console?
If you have already installed cygwin and are looking for a convenient way to install additional software from the command line, the apt-cyg tool may be just what you need. The apt-cyg tool acts as a command line installer that cooperates with the cygwin setup program and uses the same cygwin repository.

5.1. How does everything work?
There's a C library which provides a Unix-style API. The applications are linked with it and voila - they run on Windows.

The aim is to add all the goop necessary to make your apps run on Windows into the C library. Then your apps should run on Unix and Windows with no changes at the source level.

The C library is in a DLL, which makes basic applications quite small. And it allows relatively easy upgrades to the Win32/Unix translation layer, providing that DLL changes stay backward-compatible.

For a good overview of Cygwin, you may want to read the paper on Cygwin published by the Usenix Association in conjunction with the 2d Usenix NT Symposium in August 1998. It is available in HTML format on the project WWW site.

5.2. Are development snapshots for the Cygwin library available?
Yes. They're made whenever anything interesting happens inside the Cygwin library (usually roughly on a nightly basis, depending on how much is going on). They are only intended for those people who wish to contribute code to the project. If you aren't going to be happy debugging problems in a buggy snapshot, avoid these and wait for a real release. The snapshots are available from http://cygwin.com/snapshots/.

5.3. How is the DOS/Unix CR/LF thing handled?
Let's start with some background.

In UNIX, a file is a file and what the file contains is whatever the program/programmer/user told it to put into it. In Windows, a file is also a file and what the file contains depends not only on the program/programmer/user but also the file processing mode.

When processing in text mode, certain values of data are treated specially. A \n (new line) written to the file will prepend a \r (carriage return) so that if you `printf("Hello\n") you in fact get "Hello\r\n". Upon reading this combination, the \r is removed and the number of bytes returned by the read is 1 less than was actually read. This tends to confuse programs dependent on ftell and fseek. A Ctrl-Z encountered while reading a file sets the End Of File flags even though it truly isn't the end of file.

One of Cygwin's goals is to make it possible to easily mix Cygwin-ported Unix programs with generic Windows programs. As a result, Cygwin opens files in text mode as is normal under Windows. In the accompanying tools, tools that deal with binaries (e.g. objdump) operate in Unix binary mode and tools that deal with text files (e.g. bash) operate in text mode.

Some people push the notion of globally setting the default processing mode to binary via mount point options or by setting the CYGWIN environment variable. But that creates a different problem. In binary mode, the program receives all of the data in the file, including a \r. Since the programs will no longer deal with these properly for you, you would have to remove the \r from the relevant text files, especially scripts and startup resource files. This is a porter "cop out", forcing the user to deal with the \r for the porter.

It is rather easy for the porter to fix the source code by supplying the appropriate file processing mode switches to the open/fopen functions. Treat all text files as text and treat all binary files as binary. To be specific, you can select binary mode by adding O_BINARY to the second argument of an open call, or "b" to second argument of an fopen call. You can also call setmode (fd, O_BINARY).

Note that because the open/fopen switches are defined by ANSI, they exist under most flavors of Unix; open/fopen will just ignore the switch since they have no meaning to UNIX.

Explanation adapted from mailing list email by Earnie Boyd .

5.4. Is the Cygwin library multi-thread-safe?
Yes.

There is also extensive support for 'POSIX threads', see the file cygwin.din for the list of POSIX thread functions provided.

5.5. Why is some functionality only supported in Windows NT?
Windows 9x: n. 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.

But seriously, Windows 9x lacks most of the security-related calls and has several other deficiencies with respect to its version of the Win32 API. See the calls.texinfo document for more information as to what is not supported in Win 9x.

5.6. How is fork implemented?
Cygwin fork essentially works like a non-copy on write version of fork (like old Unix versions used to do). Because of this it can be a little slow. In most cases, you are better off using the spawn family of calls if possible.

Here's how it works:

Parent initializes a space in the Cygwin process table for child. Parent creates child suspended using Win32 CreateProcess call, giving the same path it was invoked with itself. Parent calls setjmp to save its own context and then sets a pointer to this in the Cygwin shared memory area (shared among all Cygwin tasks). Parent fills in the child's .data and .bss subsections by copying from its own address space into the suspended child's address space. Parent then starts the child. Parent waits on mutex for child to get to safe point. Child starts and discovers if has been forked and then longjumps using the saved jump buffer. Child sets mutex parent is waiting on and then blocks on another mutex waiting for parent to fill in its stack and heap. Parent notices child is in safe area, copies stack and heap from itself into child, releases the mutex the child is waiting on and returns from the fork call. Child wakes from blocking on mutex, recreates any mmapped areas passed to it via shared area and then returns from fork itself.

5.7. How does wildcarding (globbing) work?
If the DLL thinks it was invoked from a DOS style prompt, it runs a `globber' over the arguments provided on the command line. This means that if you type LS *.EXE from DOS, it will do what you might expect.

Beware: globbing uses malloc. If your application defines malloc, that will get used. This may do horrible things to you.

5.8. How do symbolic links work?
Cygwin knows of two ways to create symlinks.

The old method is the only valid one up to but not including version 1.3.0. If it's enabled (from 1.3.0 on by setting `nowinsymlinks' in the environment variable CYGWIN) Cygwin generates link files with a magic header. When you open a file or directory that is a link to somewhere else, it opens the file or directory listed in the magic header. Because we don't want to have to open every referenced file to check symlink status, Cygwin marks symlinks with the system attribute. Files without the system attribute are not checked. Because remote samba filesystems do not enable the system attribute by default, symlinks do not work on network drives unless you explicitly enable this attribute.

The new method which is introduced with Cygwin version 1.3.0 is enabled by default or if `winsymlinks' is set in the environment variable CYGWIN. Using this method, Cygwin generates symlinks by creating Windows shortcuts. Cygwin created shortcuts have a special header (which is in that way never created by Explorer) and the R/O attribute set. A DOS path is stored in the shortcut as usual and the description entry is used to store the POSIX path. While the POSIX path is stored as is, the DOS path has perhaps to be rearranged to result in a valid path. This may result in a divergence between the DOS and the POSIX path when symlinks are moved crossing mount points. When a user changes the shortcut, this will be detected by Cygwin and it will only use the DOS path then. While Cygwin shortcuts are shown without the ".lnk" suffix in `ls' output, non-Cygwin shortcuts are shown with the suffix. However, both are treated as symlinks.

Both, the old and the new symlinks can live peacefully together since Cygwin treats both as symlinks regardless of the setting of `(no)winsymlinks' in the environment variable CYGWIN.

5.9. Why do some files, which are not executables have the 'x' type.
When working out the Unix-style attribute bits on a file, the library has to fill out some information not provided by the WIN32 API.

It guesses that files ending in .exe and .bat are executable, as are ones which have a "#!" as their first characters.

5.10. How secure is Cygwin in a multi-user environment?
As of version 1.5.13, the Cygwin developers are not aware of any feature in the cygwin dll that would allow users to gain privileges or to access objects to which they have no rights under Windows. However there is no guarantee that Cygwin is as secure as the Windows it runs on. Cygwin processes share some variables and are thus easier targets of denial of service type of attacks.

5.11. How do the net-related functions work?
(Please note: This section has not yet been updated for the latest net release.)

The network support in Cygwin is supposed to provide the Unix API, not the Winsock API.

There are differences between the semantics of functions with the same name under the API.

E.g., the select system call on Unix can wait on a standard file handles and handles to sockets. The select call in Winsock can only wait on sockets. Because of this, cygwin.dll does a lot of nasty stuff behind the scenes, trying to persuade various Winsock/win32 functions to do what a Unix select would do.

If you are porting an application which already uses Winsock, then using the net support in Cygwin is wrong.

But you can still use native Winsock, and use Cygwin. The functions which cygwin.dll exports are called 'cygwin_ '. There are a load of defines which map the standard Unix names to the names exported by the DLL-- check out include/netdb.h:

..etc.. void		cygwin_setprotoent (int); void		cygwin_setservent (int); void		cygwin_setrpcent (int); ..etc.. #ifndef __INSIDE_CYGWIN_NET__ #define endprotoent cygwin_endprotoent #define endservent cygwin_endservent #define endrpcent cygwin_endrpcent ..etc..

The idea is that you'll get the Unix->Cygwin mapping if you include the standard Unix header files. If you use this, you won't need to link with libwinsock.a - all the net stuff is inside the DLL.

The mywinsock.h file is a standard winsock.h which has been hacked to remove the bits which conflict with the standard Unix API, or are defined in other headers. E.g., in mywinsock.h, the definition of struct hostent is removed. This is because on a Unix box, it lives in netdb. It isn't a good idea to use it in your applications.

As of the b19 release, this information may be slightly out of date.

5.12. I don't want Unix sockets, how do I use normal Win32 winsock?
To use the vanilla Win32 winsock, you just need to #define __USE_W32_WINSOCK and #include "windows.h" (or "winsock2.h" at the top of your source file(s). You may find it easier to add "-D__USE_W32_WINSOCK" to the CFLAGS settings in your makefile, if you are using one, as this will then apply to all your source files. It is also worth using "#define WIN32_LEAN_AND_MEAN" before you include the windows header file, as this will prevent it from pulling in lots of header files for all sorts of unrelated windows APIs when all you want is the Winsock definitions; again, this could be set for the entire project in your CFLAGS.

You'll also need to add -lwsock32 to the compiler's command line (or the makefile's list of link libs) so that you link against libwsock32.a.

5.13. What version numbers are associated with Cygwin?
Cygwin versioning is relatively complicated because of its status as a shared library. First of all, since October 1998 every Cygwin DLL has been named cygwin1.dll and has a 1 in the release name. Additionally, there are DLL major and minor numbers that correspond to the name of the release, and a release number. In other words, cygwin-1.5.10-2 is cygwin1.dll, major version 5, minor version 10, release 2.

The cygwin1.dll major version number gets incremented only when a change is made that makes existing software incompatible. For example, the first major version 5 release, cygwin-1.5.0-1, added 64-bit file I/O operations, which required many libraries to be recompiled and relinked. The minor version changes every time we make a new backward compatible Cygwin release available. There is also a cygwin1.dll release version number. The release number is only incremented if we update an existing release in a way that does not affect the DLL (like a missing header file).

There are also Cygwin API major and minor numbers. The major number tracks important non-backward-compatible interface changes to the API. An executable linked with an earlier major number will not be compatible with the latest DLL. The minor number tracks significant API additions or changes that will not break older executables but may be required by newly compiled ones.

Then there is a shared memory region compatibility version number. It is incremented when incompatible changes are made to the shared memory region or to any named shared mutexes, semaphores, etc. Finally there is a mount point registry version number which keeps track of non-backwards-compatible changes to the registry mount table layout. This has been mounts v2 for a long time. For more exciting Cygwin version number details, check out the /usr/include/cygwin/version.h file.

5.14. Why isn't _timezone set correctly?
(Please note: This section has not yet been updated for the latest net release.)

Did you explicitly call tzset before checking the value of _timezone? If not, you must do so.

5.15. Is there a mouse interface?
There is no way to capture mouse events from Cygwin. There are currently no plans to add support for this.

6.1. How do I contribute a package?
If you are willing to be a package maintainer, great! We urgently need volunteers to prepare and maintain packages, because the priority of the Cygwin Team is Cygwin itself.

The Cygwin Package Contributor's Guide at http://cygwin.com/setup.html details everything you need to know about being a package maintainer. The quickest way to get started is to read the Initial packaging procedure, script-based section on that page. The generic-build-script found there works well for most packages.

For questions about package maintenance, use the cygwin-apps mailing list (start at http://cygwin.com/lists.html) after searching and browsing the cygwin-apps list archives, of course. Be sure to look at the Submitting a package checklist at http://cygwin.com/setup.html before sending an ITP (Intent To Package) email to cygwin-apps.

You should also announce your intentions to the general cygwin list, in case others were thinking the same thing.

6.2. How do I contribute to Cygwin?
If you want to contribute to Cygwin itself, see http://cygwin.com/contrib.html.

6.3. Why are compiled executables so huge?!?
By default, gcc compiles in all symbols. You'll also find that gcc creates large executables on UNIX.

If that bothers you, just use the 'strip' program, part of the binutils package. Or compile with the -s option to gcc.

6.4. Where is glibc?
Cygwin does not provide glibc. It uses newlib instead, which provides much (but not all) of the same functionality. Porting glibc to Cygwin would be difficult.

6.5. Where is Objective C?
Objective C is not distributed with the Cygwin version of gcc, and there are no plans to do so. The gcc package maintainer had difficulty building it, and once built there were problems using it. It appears that there is only minimal support for the Objective C front-end in the main GCC distribution, anyway.

6.6. Why does my make fail on Cygwin with an execvp error?
First of all, if you are using make -j[N], then stop. It doesn't work well. Also beware of using non-portable shell features in your Makefiles (see tips at http://cygwin.com/faq/faq.using.html#faq.using.shell-scripts).

Errors of make: execvp: /bin/sh: Illegal Argument or make: execvp: /bin/sh: Argument list too long are often caused by the command-line being too long for the Windows execution model. To circumvent this, mount the path of the executable using the -X switch to enable cygexec for all executables in that folder; you will also need to exclude non-cygwin executables with the -x switch. Enabling cygexec causes cygwin executables to talk directly to one another, which increases the command-line limit. To enable cygexec for /bin and /usr/bin, you can use these commands in a batch file:

mount -X -b -f c:\cygwin\bin /bin mount -X -b -f c:\cygwin\bin /usr/bin mount -x -b -f c:\cygwin\bin\tclsh84.exe /usr/bin/tclsh84.exe mount -x -b -f c:\cygwin\bin\tclsh84.exe /bin/tclsh84.exe mount -x -b -f c:\cygwin\bin\wish84.exe /usr/bin/wish84.exe mount -x -b -f c:\cygwin\bin\wish84.exe /bin/wish84.exe

Note that if you have Tcl/Tk installed, you must specifically exclude tclsh84 and wish84, which are linked to the Cygwin DLL but are not actually Cygwin programs. If you have added other non-Cygwin programs to a path you want to mount cygexec, you can find them with a script like this:

cd /bin; for f in `find. -type f -name '*.exe'`; do       cygcheck $f | (fgrep -qi cygwin1.dll || echo $f) done
 * 1) !/bin/sh

See http://www.cygwin.com/cygwin-ug-net/using-utils.html#mount for more information on using mount.

6.7. How can I use IPC, or why do I get a Bad system call error?
Try running cygserver. Read http://www.cygwin.com/cygwin-ug-net/using-cygserver.html. If you're trying to use PostgreSQL, also read /usr/share/doc/Cygwin/postgresql-*.README.

6.8. Why the undefined reference to WinMain@16?
If you're using gcc, try adding an empty main function to one of your sources. Or, perhaps you have -lm too early in the link command line. It should be at the end:

bash$ gcc hello.c -lm bash$ ./a.exe Hello World!

works, but

bash$ gcc -lm hello.c   /c/TEMP/ccjLEGlU.o(.text+0x10):hello.c: multiple definition of `main' /usr/lib/libm.a(libcmain.o)(.text+0x0):libcmain.c: first defined here /usr/lib/libm.a(libcmain.o)(.text+0x6a):libcmain.c: undefined reference to `WinMain@16' collect2: ld returned 1 exit status

If you're using GCJ, you need to pass a "--main" flag:

gcj --main=Hello Hello.java

6.9. How do I use Win32 API calls?
(Please note: This section has not yet been updated for the latest net release.)

It's pretty simple actually. Cygwin tools require that you explicitly link the import libraries for whatever Win32 API functions that you are going to use, with the exception of kernel32, which is linked automatically (because the startup and/or built-in code uses it).

For example, to use graphics functions (GDI) you must link with gdi32 like this: gcc -o foo.exe foo.o bar.o -lgdi32

or (compiling and linking in one step):

gcc -o foo.exe foo.c bar.c -lgdi32

The following libraries are available for use in this way:

advapi32 largeint ole32 scrnsave vfw32 cap lz32 oleaut32 shell32 win32spl comctl32 mapi32 oledlg snmp winmm comdlg32 mfcuia32 olepro32 svrapi winserve ctl3d32 mgmtapi opengl32 tapi32 winspool dlcapi mpr penwin32 th32 winstrm gdi32 msacm32 pkpd32 thunk32 wow32 glaux nddeapi rasapi32 url wsock32 glu32 netapi32 rpcdce4 user32 wst icmp odbc32 rpcndr uuid imm32 odbccp32 rpcns4 vdmdbg kernel32 oldnames rpcrt4 version

The regular setup allows you to use the option -mwindows on the command line to include a set of the basic libraries (and also make your program a GUI program instead of a console program), including user32, gdi32 and, IIRC, comdlg32.

Note that you should never include -lkernel32 on your link line unless you are invoking ld directly. Do not include the same import library twice on your link line. Finally, it is a good idea to put import libraries last on your link line, or at least after all the object files and static libraries that reference them.

The first two are related to problems the linker has (as of b18 at least) when import libraries are referenced twice. Tables get messed up and programs crash randomly. The last point has to do with the fact that gcc processes the files listed on the command line in sequence and will only resolve references to libraries if they are given after the file that makes the reference.

6.10. How do I compile a Win32 executable that doesn't use Cygwin?
The -mno-cygwin flag to gcc makes gcc link against standard Microsoft DLLs instead of Cygwin. This is desirable for native Windows programs that don't need a UNIX emulation layer.

This is not to be confused with 'MinGW' (Minimalist GNU for Windows), which is a completely separate effort. That project's home page is http://www.mingw.org/index.shtml.

6.11. Can I build a Cygwin program that does not require cygwin1.dll at runtime?
No. If your program uses the Cygwin API, then your executable cannot run without cygwin1.dll. In particular, it is not possible to statically link with a Cygwin library to obtain an independent, self-contained executable.

If this is an issue because you intend to distribute your Cygwin application, then you had better read and understand http://cygwin.com/licensing.html, which explains the licensing options. Unless you purchase a special commercial license from Red Hat, then your Cygwin application must be Open Source.

6.12. Can I link with both MSVCRT*.DLL and cygwin1.dll?
No, you must use one or the other, they are mutually exclusive.

6.13. How do I make the console window go away?
The default during compilation is to produce a console application. It you are writing a GUI program, you should either compile with -mwindows as explained above, or add the string "-Wl,--subsystem,windows" to the GCC command line.

6.14. Why does make complain about a "missing separator"?
This problem usually occurs as a result of someone editing a Makefile with a text editor that replaces tab characters with spaces. Command lines must start with tabs. This is not specific to Cygwin.

6.15. Why can't we redistribute Microsoft's Win32 headers?
Subsection 2.d.f of the `Microsoft Open Tools License agreement' looks like it says that one may not "permit further redistribution of the Redistributables to their end users". We take this to mean that we can give them to you, but you can't give them to anyone else, which is something that we can't agree to. Fortunately, we have our own Win32 headers which are pretty complete.

6.16. How do I use cygwin1.dll with Visual Studio or MinGW?
Before you begin, note that Cygwin is licensed under the GNU GPL (as indeed are all other Cygwin-based libraries). That means that if your code links against the cygwin dll (and if your program is calling functions from Cygwin, it must, as a matter of fact, be linked against it), you must apply the GPL to your source as well. Of course, this only matters if you plan to distribute your program in binary form. For more information, see http://gnu.org/licenses/gpl-faq.html. If that is not a problem, read on.

If you want to load the DLL dynamically, read winsup/cygwin/how-cygtls-works.txt and the sample code in winsup/testsuite/cygload to understand how this works. The short version is:

Make sure you have 4K of scratch space at the bottom of your stack.

Invoke cygwin_dll_init:

HMODULE h = LoadLibrary("cygwin1.dll"); void (*init) = GetProcAddress(h, "cygwin_dll_init"); init;

If you want to link statically from Visual Studio, to my knowledge none of the Cygwin developers have done this, but we have this report from the mailing list that it can be done this way:

Use the impdef program to generate a .def file for the cygwin1.dll (if you build the cygwin dll from source, you will already have a def file)

impdef cygwin1.dll > cygwin1.def

Use the MS VS linker (lib) to generate an import library

lib /def=cygwin1.def /out=cygwin1.lib

Create a file "my_crt0.c" with the following contents


 * 1) include 
 * 2) include 

typedef int (*MainFunc) (int argc, char *argv[], char **env);

void my_crt0 (MainFunc f) { cygwin_crt0(f); }

Use gcc in a Cygwin prompt to build my_crt0.c into a DLL (e.g. my_crt0.dll). Follow steps 1 and 2 to generate .def and .lib files for the DLL.

Download crt0.c from the cygwin website and include it in your sources. Modify it to call my_crt0 instead of cygwin_crt0.

Build your object files using the MS VC compiler cl.

Link your object files, cygwin1.lib, and my_crt0.lib (or whatever you called it) into the executable.

Note that if you are using any other Cygwin based libraries that you will probably need to build them as DLLs using gcc and then generate import libraries for the MS VC linker.

Thanks to Alastair Growcott (agrowcot at cisco dot com) for this tip.

6.17. How do I link against a .lib file?

If your .lib file is a normal static or import library with C-callable entry points, you can list foo.lib as an object file for gcc/g++, just like any *.o file. Otherwise, here are some steps:


 * 1) Build a C file with a function table. Put all functions you intend to use in that table. This forces the linker to include all the object files from the .lib. Maybe there is an option to force LINK.EXE to include an object file.
 * 2) Build a dummy 'LibMain'.
 * 3) Build a .def with all the exports you need.
 * 4) Link with your .lib using link.exe.

or


 * 1) Extract all the object files from the .lib using LIB.EXE.
 * 2) Build a dummy C file referencing all the functions you need, either with a direct call or through an initialized function pointer.
 * 3) Build a dummy LibMain.
 * 4) Link all the objects with this file+LibMain.
 * 5) Write a .def.
 * 6) Link.

You can use these methods to use MSVC (and many other runtime libs) with Cygwin development tools.

Note that this is a lot of work (half a day or so), but much less than rewriting the runtime library in question from specs...

Thanks to Jacob Navia (root at jacob dot remcomp dot fr) for this explanation.

6.18. How do I build Cygwin on my own?
First, you need to make sure you have the necessary build tools installed; you at least need gcc, make, perl, and cocom. If you want to run the tests, dejagnu is also required, and you need to have CYGWIN=server set as described at http://www.cygwin.com/cygwin-ug-net/using-cygserver.html. Normally, building ignores any errors in building the documentation, which requires the docbook-xml42, docbook-xsl, and xmlto packages. For more information on building the documentation, see the README included in the cygwin-doc package.

Next, get the Cygwin source. Ideally, you should check out what you need from CVS (http://cygwin.com/cvs.html). This is the preferred method for acquiring the sources. Otherwise, if you are trying to duplicate a cygwin release then you should download the corresponding source package (cygwin-x.y.z-n-src.tar.bz2).

You must build cygwin in a separate directory from the source, so create something like a build/ directory. Assuming you checked out the source in /oss/src/, and you also want to install to the temporary location install:

mkdir /oss/build mkdir /oss/install cd build (/oss/src/configure --prefix=/oss/install -v; make) >& make.out make install > install.log 2>&1

To check a cygwin1.dll, run "make check" in the build/i?86*cygwin/winsup directory created after running make above. If that works, install everything except the dll (if you can). Then, close down all cygwin programs (including bash windows, inetd, etc.), save your old dll, and copy the new dll to the correct place. Then start up a bash window, or run a cygwin program from the Windows command prompt, and see what happens.

If you get the error "shared region is corrupted" it means that two different versions of cygwin1.dll are running on your machine at the same time. Remove all but one.

6.19. I may have found a bug in Cygwin, how can I debug it (the symbols in gdb look funny)?
Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so we recommend trying the latest snapshot from http://cygwin.com/snapshots/ or building the DLL from CVS.

To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq-nochunks.html#faq.programming.building-cygwin. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome).

6.20. How can I compile Cygwin for an unsupported platform (PowerPC, Alpha, ARM, Itanium)?
Unfortunately, this will be difficult. Exception handling and signals support semantics and args have been designed for x86 so you would need to write specific support for your platform. We don't know of any other incompatibilities. Please send us patches if you do this work!

6.21. How can I adjust the heap/stack size of an application?
If you need to change the maximum amount of memory available to Cygwin, see http://cygwin.com/cygwin-ug-net/setup-maxmem.html. Otherwise, just pass heap/stack linker arguments to gcc. To create foo.exe with a heap size of 200MB and a stack size of 8MB, you would invoke gcc as:

gcc -Wl,--heap,200000000,--stack,8000000 -o foo foo.c

6.22. How can I find out which DLLs are needed by an executable?
objdump -p

provides this information, but is rather verbose. cygcheck will do this much more concisely, and operates recursively, provided the command is in your path.

Note there is currently a bug in cygcheck in that it will not report on a program in a Windows system dir (e.g., C:\Windows or C:\WINNT) even if it's in your path. To work around this, supply the full Win32 path to the executable, including the .exe extension:

cygcheck c:\\winnt\\system32\\cmd.exe

(Note the windows path separator must be escaped if this is typed in bash.)

6.23. How do I build a DLL?
There's documentation that explains the process in the Cygwin User's Guide here: http://cygwin.com/cygwin-ug-net/dll.html

6.24. How can I set a breakpoint at MainCRTStartup?
(Please note: This section has not yet been updated for the latest net release.) Set a breakpoint at *0x401000 in gdb and then run the program in question.

6.25. How can I build a relocatable dll?
(Please note: This section has not yet been updated for the latest net release. However, there was a discussion on the cygwin mailing list recently that addresses this issue. Read http://cygwin.com/ml/cygwin/2000-06/msg00688.html and related messages.)

You must execute the following sequence of five commands, in this order:

$(LD) -s --base-file BASEFILE --dll -o DLLNAME OBJS LIBS -e ENTRY

$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \ --base-file BASEFILE --output-exp EXPFILE

$(LD) -s --base-file BASEFILE EXPFILE -dll -o DLLNAME OBJS LIBS -e ENTRY

$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \ --base-file BASEFILE --output-exp EXPFILE

$(LD) EXPFILE --dll -o DLLNAME OBJS LIBS -e ENTRY

In this example,
 * $(LD) is the linker, ld.
 * $(DLLTOOL) is dlltool.
 * $(AS) is the assembler, as.
 * DLLNAME is the name of the DLL you want to create, e.g., tcl80.dll.
 * OBJS is the list of object files you want to put into the DLL.
 * LIBS is the list of libraries you want to link the DLL against. For example, you may or may not want -lcygwin. You may want -lkernel32. Tcl links against -lcygwin -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lkernel32.
 * DEFFILE is the name of your definitions file. A simple DEFFILE would consist of "EXPORTS" followed by a list of all symbols which should be exported from the DLL. Each symbol should be on a line by itself. Other programs will only be able to access the listed symbols.
 * BASEFILE is a temporary file that is used during this five stage process, e.g., tcl.base.
 * EXPFILE is another temporary file, e.g., tcl.exp.
 * ENTRY is the name of the function which you want to use as the entry point. This function should be defined using the WINAPI attribute, and should take three arguments: int WINAPI startup (HINSTANCE, DWORD, LPVOID). This means that the actual symbol name will have an appended @12, so if your entry point really is named startup, the string you should use for ENTRY in the above examples would be startup@12. If your DLL calls any Cygwin API functions, the entry function will need to initialize the Cygwin impure pointer. You can do that by declaring a global variable _impure_ptr, and then initializing it in the entry function. Be careful not to export the global variable _impure_ptr from your DLL; that is, do not put it in DEFFILE.

/* This is a global variable. */ struct _reent *_impure_ptr; extern struct _reent *__imp_reent_data;

int entry (HINSTANT hinst, DWORD reason, LPVOID reserved) { _impure_ptr = __imp_reent_data; /* Whatever else you want to do. */ }

You may put an optional `--subsystem windows' on the $(LD) lines. The Tcl build does this, but I admit that I no longer remember whether this is important. Note that if you specify a --subsytem  flag to ld, the -e entry must come after the subsystem flag, since the subsystem flag sets a different default entry point.

You may put an optional `--image-base BASEADDR' on the $(LD) lines. This will set the default image base. Programs using this DLL will start up a bit faster if each DLL occupies a different portion of the address space. Each DLL starts at the image base, and continues for whatever size it occupies.

Now that you've built your DLL, you may want to build a library so that other programs can link against it. This is not required: you could always use the DLL via LoadLibrary. However, if you want to be able to link directly against the DLL, you need to create a library. Do that like this:

$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE --output-lib LIBFILE

$(DLLTOOL), $(AS), DLLNAME, and DEFFILE are the same as above. Make sure you use the same DLLNAME and DEFFILE, or things won't work right.

LIBFILE is the name of the library you want to create, e.g., libtcl80.a. You can then link against that library using something like -ltcl80 in your linker command.

6.26. How can I debug what's going on?
You can debug your application using gdb. Make sure you compile it with the -g flag! If your application calls functions in MS DLLs, gdb will complain about not being able to load debug information for them when you run your program. This is normal since these DLLs don't contain debugging information (and even if they did, that debug info would not be compatible with gdb).

6.27. Can I use a system trace mechanism instead?
Yes. You can use the strace.exe utility to run other cygwin programs with various debug and trace messages enabled. For information on using strace, see the Cygwin User's Guide or the file winsup/utils/utils.sgml.

6.28. Why doesn't gdb handle signals?
Unfortunately, there is only minimal signal handling support in gdb currently. Signal handling only works with Windows-type signals. SIGINT may work, SIGFPE may work, SIGSEGV definitely does. You cannot 'stop', 'print' or 'nopass' signals like SIGUSR1 or SIGHUP to the process being debugged.

6.29. The linker complains that it can't find something.
A common error is to put the library on the command line before the thing that needs things from it.

This is wrong: gcc -lstdc++ hello.cc This is right: gcc hello.cc -lstdc++

6.30. Why do I get an error using struct stat64?
struct stat64 is not used in Cygwin, just use struct stat.

6.31. I use a function I know is in the API, but I still get a link error.
The function probably isn't declared in the header files, or the UNICODE stuff for it isn't filled in.

6.32. Can you make DLLs that are linked against libc ?
Yes.

6.33. Where is malloc.h?
(Please note: This section has not yet been updated for the latest net release.)

Include stdlib.h instead of malloc.h.

6.34. Can I use my own malloc?
If you define a function called malloc in your own code, and link with the DLL, the DLL will call your malloc. Needless to say, you will run into serious problems if your malloc is buggy.

If you run any programs from the DOS command prompt, rather than from in bash, the DLL will try and expand the wildcards on the command line. This process uses malloc before your main line is started. If you have written your own malloc to need some initialization to occur after main is called, then this will surely break.

Moreover, there is an outstanding issue with _malloc_r in newlib. This re-entrant version of malloc will be called directly from within newlib, by-passing your custom version, and is probably incompatible with it. But it may not be possible to replace _malloc_r too, because cygwin1.dll does not export it and Cygwin does not expect your program to replace it. This is really a newlib issue, but we are open to suggestions on how to deal with it.

6.35. Can I mix objects compiled with msvc++ and gcc?
Yes, but only if you are combining C object files. MSVC C++ uses a different mangling scheme than GNU C++, so you will have difficulties combining C++ objects.

6.36. Can I use the gdb debugger to debug programs built by VC++?
No, not for full (high level source language) debugging. The Microsoft cmpilers generate a different type of debugging symbol information, which gdb does not understand.

However, the low-level (assembly-type) symbols generated by Microsoft compilers are coff, which gdb DOES understand. Therefore you should at least be able to see all of your global symbols; you just won't have any information about data types, line numbers, local variables etc.

6.37. Where can I find info on x86 assembly?
CPU reference manuals for Intel's current chips are available in downloadable PDF form on Intel's web site:

http://developer.intel.com/design/pro/manuals/

6.38. Shell scripts aren't running properly from my makefiles?
If your scripts are in the current directory, you must have. (dot) in your $PATH. (It is not normally there by default.) Otherwise, you would need to add /bin/sh in front of each and every shell script invoked in your Makefiles.

6.39. What preprocessor macros do I need to know about?
We use _WIN32 to signify access to the Win32 API and __CYGWIN__ for access to the Cygwin environment provided by the dll.

We chose _WIN32 because this is what Microsoft defines in VC++ and we thought it would be a good idea for compatibility with VC++ code to follow their example. We use _MFC_VER to indicate code that should be compiled with VC++.

_WIN32 is only defined when you use either the -mno-cygwin or -mwin32 gcc command line options. This is because Cygwin is supposed to be a Unix emulation environment and defining _WIN32 confuses some programs which think that they have to make special concessions for a Windows environment which Cygwin handles automatically.

Note that using -mno-cygwin replaces __CYGWIN__ with __MINGW32__ as to tell which compiler (or settings) you're running. Check this out in detail by running, for example

$ gcc -dM -E -xc /dev/null >gcc.txt $ gcc -mno-cygwin -dM -E -xc /dev/null >gcc-mno-cygwin.txt $ gcc -mwin32 -dM -E -xc /dev/null >gcc-mwin32.txt

Then use the diff and grep utilities to check what the difference is.

6.40. How should I port my Unix GUI to Windows?
There are two basic strategies for porting Unix GUIs to Windows.

The first is to use a portable graphics library such as tcl/tk, X11, or V (and others?). Typically, you will end up with a GUI on Windows that requires some runtime support. With tcl/tk, you'll want to include the necessary library files and the tcl/tk DLLs. In the case of X11, you'll need everyone using your program to have an X11 server installed.

The second method is to rewrite your GUI using Win32 API calls (or MFC with VC++). If your program is written in a fairly modular fashion, you may still want to use Cygwin if your program contains a lot of shared (non-GUI-related) code. That way you still gain some of the portability advantages inherent in using Cygwin.

6.41. Why not use DJGPP ?
DJGPP is a similar idea, but for DOS instead of Win32. DJGPP uses a "DOS extender" to provide a more reasonable operating interface for its applications. The Cygwin toolset doesn't have to do this since all of the applications are native WIN32. Applications compiled with the Cygwin tools can access the Win32 API functions, so you can write programs which use the Windows GUI.

You can get more info on DJGPP by following http://www.delorie.com/.

7.1. Pipe key (|) doesn't work on non-US keyboards in Win9x/ME
This might get fixed someday, but meanwhile, just use rxvt, which does not have this problem. This is no real loss, because rxvt has many other advantages. (Do not attempt to use the "broken" pipe key (¦) as a substitute, it is a different character.)

7.2. Cannot access tape devices with mt on Win9x
Win9x does not support the API used by the Cygwin fhandler_dev_tape class. Details at http://sources.redhat.com/ml/cygwin/2000-12/msg00331.html.

7.3. On Win9x, scp leaves ssh processes running.
Aware of the problem, no solution known. You can stop them by hand with the Task Manager.