If you have installed Cygwin, you can find lots of documentation in
`/usr/share/doc/'. 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.)
In addition, some packages have Cygwin specific instructions in a file
`/usr/share/doc/Cygwin/package_name.README'. 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.)
Comprehensive information about the Cygwin mailing lists can be found at `http://cygwin.com/lists.html'.
To subscribe to the main list, send a message to cygwin-subscribe@cygwin.com. To unsubscribe from the main list, send a message to cygwin-unsubscribe@cygwin.com. In both cases, the subject and body of the message are ignored.
Similarly, to subscribe to the Cygwin announcements list, send a message to cygwin-announce-subscribe@cygwin.com. To unsubscribe, send a message to cygwin-announce-unsubscribe@cygwin.com.
If you are going to help develop the Cygwin library by volunteering for the project, you will want to subscribe to the Cygwin developers list, called cygwin-developers. If you are contributing to Cygwin tools & applications, rather than the library itself, then you should subscribe to cygwin-apps. The same mechanism as described for the first two lists works for these as well. Both cygwin-developers and cygwin-apps are by-approval lists.
There is a searchable archive of the main mailing list at `http://cygwin.com/ml/cygwin/'. There is an alternate archive, also searchable, at `http://www.delorie.com/archives/'. You can also search at `http://www.google.com/' and include "cygwin" in the list of search terms.
Cygwin mailing lists are not gatewayed to USENET, so anti-spam measures in your email address are neither required nor appreciated. Also, avoid sending HTML content to Cygwin mailing lists.
If you follow these guidelines, you are much more likely to get a helpful response from the Cygwin developers and/or the Cygwin community at large:
If you do not follow the above guidelines, you may still elicit a response, but you may not appreciate it!
For inquiries about support contracts and commercial licensing, visit `http://www.redhat.com/software/cygwin/'.
Beyond that, perhaps nobody has time to answer your question. Perhaps nobody knows the answer.
If you upgraded recently, and suddenly vim (or some other Cygwin
application) cannot find cygncurses5.dll
, it 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'.
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'.
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/$/;/'`"
The `SYSTEM' user cannot access network shares that require authentication. 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), or running the service as your own user with `cygrunsrv -u' (see `/usr/share/doc/Cygwin/cygrunsrv.README' for more information).
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.
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!
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.
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.
Add the following to your ~/.bashrc
file:
shopt -s nocaseglob
and add the following to your ~/.inputrc
file:
set completion-ignore-case on
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
This is only valid up to but not including version 1.3.0:
Cygwin does not follow MS Windows Explorer Shortcuts (*.lnk files). It sees a shortcut as a regular file and this you cannot "cd" into it.
Some people have suggested replacing the current symbolic link scheme with shortcuts. The major problem with this is that .LNK files would then be used to symlink Cygwin paths that may or may not be valid under native Win32 non-Cygwin applications such as Explorer.
Since version 1.3.0, Cygwin treats shortcuts as symlinks.
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.
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.
Even after installing the `man' package, you get an error like this:
bash-2.04$ man man Error executing formatting or display command. System command (cd /usr/man ; (echo -e ".pl 1100i"; cat /usr/man/man1/man.1; echo ".pl \n(nlu+10") | /usr/bin/tbl | /usr/bin/groff -Tascii -mandoc | less -is) exited with status 32512. No manual entry for man
You also need /bin/sh, which is found in the `ash' package. You must install this too.
In addition, 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).
`ntsec' will allow UNIX permissions in Windows NT on NTFS file systems. This is on by default (a recent change).
`ntea' works on NTFS and FAT but it creates a huge, undeletable file on FAT filesystems.
(The `ntsec' and `ntea' settings are values for the `CYGWIN' environment variable. See the Cygwin User's Guide at `http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html' for more information on this variable and its settings.)
There is no solution at all for Windows 9x.
If you have an application that requires a certain permission mode on a file, you may be able to work around this requirement by modifying the application's source code. For a hint, based on work done by Corinna Vinschen for OpenSSH, see this message from the cygwin mailing list: `http://cygwin.com/ml/cygwin/2000-11/msg01176.html'.
Unfortunately, you cannot do something like this:
bash$ mkdir -p //MACHINE/Share/path/to/new/dir mkdir: cannot create directory `//MACHINE': No such file or directory
This is because mkdir checks for the existence of each directory on the path, creating them as necessary. Since `//MACHINE' is not a directory (you can't cd to it either), mkdir tries to create it, and fails.
This might get fixed someday, but for now, you have to work around it:
bash$ cd //MACHINE/Share bash$ mkdir -p path/to/new/dir
There are two basic problems you might run into. One is the fact that /bin/sh is really ash, and is missing some features you might expect in /bin/sh, particularly if you are used to /bin/sh actually being bash (Linux) or ksh (Tru64). For example:
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
: # This is the 2nd line, assume processing by /bin/sh
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.
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.
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 (£هنِ) 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 set meta-flag on
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.
(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).
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.
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).
If you are looking for the "more" pager, you should use the "less" pager instead.
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 below.
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 <drive>:/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.
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
(Please note: This section has not yet been updated for the latest net release.)
This usually means that you are trying to mount to a location already in use by mount. For example, if c: is mounted as '/' and you try to mount d: there as well, you will get this error message. First "umount" the old location, then "mount" the new one and you should have better luck.
If you are trying to umount '/' and are getting this message, you may
need to run regedit.exe
and change the "native" key for the '/'
mount in one of the mount points kept under
HKEY_CURRENT_USER/Software/Red Hat, Inc./CYGWIN.DLL setup/<version>
where <version> is the latest registry version associated with the
Cygwin library.
During development, we have both Unix boxes running Samba and NT/Windows 95/98 machines. We often build with cross-compilers under Unix 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.
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.
In releases prior to beta 16, mount had a special mixed case option which renamed files in such a way as to allow mixed case filenames. We chose to remove the support when we rewrote the path handling code for beta 16. The standard Windows apps -- explorer.exe, cmd.exe/command.com, etc. -- do not distinguish filenames that differed only in case, resulting in some (very) undesirable behavior.
Sergey Okhapkin had maintained a mixed-case patch ('coolview') until about B20.1, but this has not been updated to recent versions of Cygwin.
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.
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.
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?)
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.
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. Use Cygwin Setup to install either one (or both).
If you want GNU Emacs with a native Microsoft Windows interface, but without X, then you must 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 process-coding-system-alist '(("bash" . undecided-unix))) (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.
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'.
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.
Don't invoke as simply "rxvt" because that will run /bin/sh (really
ash) which is not a good interactive shell. For details see
/usr/share/doc/Cygwin/rxvt-<ver>.README
.
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.
"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).
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.
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?
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.
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.
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/
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 <earnie_boyd@yahoo.com>.
Yes.
There is also extensive support for 'POSIX threads', see the file
cygwin.din
for the list of POSIX thread functions provided.
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.
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.
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.
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.
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.
Cygwin is not secure in a multi-user environment. For example if you have a long running daemon such as "inetd" running as admin while ordinary users are logged in, or if you have a user logged in remotely while another user is logged into the console, one cygwin client can trick another into running code for it. In this way one user may gain the privilege of another cygwin program running on the machine. This is because cygwin has shared state that is accessible by all processes.
(Thanks to Tim Newsham (newsham@lava.net) for this explanation).
(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_<name>'. 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.
(Please note: This section has not yet been updated for the latest net release.)
To use the vanilla Win32 winsock, you just need to #define Win32_Winsock and #include "windows.h" at the top of your source file(s). You'll also want to add -lwsock32 to the compiler's command line so you link against libwsock32.a.
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 effect 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.
(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.
There is no way to capture mouse events from Cygwin. There are currently no plans to add support for this.
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 is at `http://cygwin.com/setup.html', which details everything you need to know about being a package maintainer. Use the cygwin-apps mailing list (start at `http://cygwin.com/lists.html') for questions about package maintenance, after searching and browsing the cygwin-apps list archives, of course. Charles Wilson posted a short recipe of what is involved, using texinfo as an example, available at `http://cygwin.com/ml/cygwin-apps/2000-11/msg00055.html'. This should give you an idea of what is required.
You should announce your intentions to the general cygwin list, in case others were thinking the same thing.
If you want to contribute to Cygwin itself, see `http://cygwin.com/contrib.html'.
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.
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.
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.
First of all, if you are using `make -j[N]', then stop. It doesn't work well.
Otherwise, read on...
Make has two operating modes, UNIX and WIN32. You need to make sure that you are operating in the right mode.
In UNIX mode, make uses sh.exe as a subshell. The path list separator is ':', '\' is the escape character, POSIX paths are expected, and Cygwin mounts will be understood. Use this for Makefiles written for UNIX.
In WIN32 mode, make uses the "native" command shell (cmd.exe or command.com), with all the restrictions that implies. The path list separator is ';', the path separator is '\', "copy" and "del" work, but the Cygwin mount table is not understood. Use this for nmake-style Makefiles.
The default mode for the Net Release of make (the one installed by
setup.exe
) is UNIX. The default mode for commercial releases to
Redhat (formerly Cygnus) customers is WIN32.
You can override the default by setting the environment variable MAKE_MODE to "UNIX" (actually case is not significant) or "WIN32" (actually anything other than "UNIX"). You can also specify the options --unix or --win32 on the make command line.
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
This is an artifact of libm.a being a symbolic link to libcygwin.a.
If you're using GCJ, you need to pass a "--main" flag:
gcj --main=Hello Hello.java
(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.
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'.
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.
No, you must use one or the other, they are mutually exclusive.
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.
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.
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 Red Hat can't agree to. Fortunately, we have our own Win32 headers which are pretty complete.
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:
impdef cygwin1.dll > cygwin1.def
lib /def=cygwin1.def /out=cygwin1.lib
#include <sys/cygwin.h> #include <stdlib.h> typedef int (*MainFunc) (int argc, char *argv[], char **env); void my_crt0 (MainFunc f) { cygwin_crt0(f); }
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 (alastair dot growcott at bakbone dot co dot uk) for this tip.
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:
or
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.
Install all required components in one directory (we'll call it /src). 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, you can install the appropriate source packages from the cygwin distribution.
As of this writing, you need to install at least the cygwin source package and the w32api source package. The winsup source package should be extracted first and the w32api source directory should be extracted into the resulting 'winsup' directory. Then rename w32api-whatever to w32api.
It is possible that the cygwin source package may require a newer version of the w32api package since the release of the packages is not always in lock step (another reason to just use CVS).
You must build cygwin in a separate directory from the source. So, create something like a /obj directory. You'll be performing your build in that directory:
bash cd /obj /src/configure --prefix=/install -v > configure.log 2>&1 make > make.log 2>&1 make install > install.log 2>&1
Normally, this procedure ignore errors in building the documentation, which requires tools which are not included in the Cygwin distribution. If you want to build the documentation on Linux, on most distributions a package named docbook-utils should get you most of what you need. For more information on building the documentation, see the README included in the cygwin-doc package.
To check a cygwin1.dll, run "make check" in the winsup/cygwin directory. 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.
(Please note: This section has not yet been updated for the latest net release.)
Unfortunately, this will be difficult. It hasn't been built for some time (late 1996) since Microsoft has dropped development of powerpc NT. Exception handling/signals support semantics/args have been changed for x86 and not updated for ppc so the ppc specific support would have to be rewritten. We don't know of any other incompatibilities. Please send us patches if you do this work!
(Please note: This section has not yet been updated for the latest net release.)
We have not ported the tools to Alpha NT and do not have plans to do so at the present time. We would be happy to add support for Alpha NT if someone contributes the changes to us.
(Please note: This section has not yet been updated for the latest net release.)
Pass heap/stack linker arguments to gcc. To create foo.exe with a heap size of 1024 and a stack size of 4096, you would invoke gcc as:
gcc -Wl,--heap,1024,--stack,4096 -o foo foo.c
`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.)
(Please note: This section has not yet been updated for the latest net release.)
There's documentation that explains the process on the main Cygwin project web page (http://cygwin.com/).
(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.
(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 <x> 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.
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).
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
.
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.
(Please note: This section has not yet been updated for the latest net release.)
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++
.
(Please note: This section has not yet been updated for the latest net release.)
The function probably isn't declared in the header files, or the UNICODE stuff for it isn't filled in.
(Please note: This section has not yet been updated for the latest net release.)
Yes.
(Please note: This section has not yet been updated for the latest net release.)
Include stdlib.h instead of malloc.h.
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.
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.
No, not for full (high level source language) debugging. The Microsoft compilers 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.
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/'
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.
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.
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.
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/'.
Go to the first, previous, next, last section, table of contents.