This page describes the gcc-nocygwin toolset, which builds Boost using the -mno-cygwin option of the Cygwin gcc compiler. This avoids introducing dependencies on the Cygwin Unix-emulation layer, allowing you to build Windows executables which are not dependant on cygwin1.dll. If you're not worried about having the dependencies, you should probably be using the plain gcc toolset.
The other option for producing windows-native executables with gcc is the mingw version of gcc with the mingw toolset. However, if you're already using Cygwin, this toolset could save you having to install an additional compiler.
This toolset operates in one of two modes - the default mode (which is
recommended) just extends the gcc toolset (configuration details here). You can
force the gcc-nocygwin toolset to extend gcc-stlport instead by setting
You can set any of the configuration variables in your environment or on
the bjam command line using options of the form
-sVARIABLE_NAME=value. The following table lists
the additional configuration variables introduced by gcc-nocygwin.
||The gcc toolset usually forces the linker to export all symbols
from the DLLs it builds. There are some hacks in ld to prevent any
symbols from the run-time library being exported, but old versions of
ld don't have this support. If necessary, you can re-enable exporting
all symbols by setting this variable to the empty string
||Use the STLport standard library instead of gcc's own library.||empty||This option is provided for backwards compatability with the original gcc-nocygwin toolset, which used to rely on the STLport standard library. Setting a value for this variable forces gcc-nocygwin to extend the gcc-stlport toolset (configuration details here). The value you set is irrelevant, unless you want to use the STLport iostream implementation|
The easiest way to use this toolset is with a recent Cygwin gcc
installation (roughly speaking, installed since October 2002). The Cygwin
setup utility should add all necessary components of gcc automatically when
you install or upgrade gcc. Basically, if an iostream-based "hello world"
program compiles and links using
g++ -mno-cygwin, you should
It is also possible to add support manually to older Cygwin compilers if you won't upgrade for some reason. See for instance these details, or search for "mno-cygwin" and "c++" on the web or the Cygwin mailing lists.
Another, probably more difficult option, is to install the STLport standard library and build it with the -mno-cygwin option. Some details are provided in the next section.
Here's the procedure for using the STLport iostream libraries with gcc-nocygwin:
NOCYGWIN_STLPORT_LIB_IDvariable to the library base name (e.g. stlport_cygwin)
Point 1 above is a little tricky using the Cygwin compiler because the current release of STLport (4.5.3) does not provide a suitable makefile. Here's a command line to make it work (run from the stlport src directory):
You may get some errors for missing include files like
. This is most easily fixed by
creating a symbolic link to the mingw include directory so that STLport can
find it under the expected name. The mingw directory is probably in
/usr/include, so you would do
in that directory. Note that this link may cause
problems when building a regular Cygwin version of STLport.
If you have a recent version of gcc (e.g. 3.2), you might get a heap of
errors for include files like
The libstdc++ directory is probably something like
, in which case you would use
As of 2002/01/24, some of the Boost test library DLLs don't link because of unresolved externals. This problem is shared by the mingw toolset.
Written May 2002 and revised January 2003 by Raoul Gough