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.

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. 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 to 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:

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

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

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.

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

(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 we can't agree to. Fortunately, we have our own Win32 headers which are pretty complete.

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:

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:

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.

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.

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

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!

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

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

There's documentation that explains the process in the Cygwin User's Guide here: http://cygwin.com/cygwin-ug-net/dll.html

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

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

struct stat64 is not used in Cygwin, just use struct stat.

The function probably isn't declared in the header files, or the UNICODE stuff for it isn't filled in.

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