|
Boost.Buildgcc-nocygwin toolset |
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 NOCYGWIN_STLPORT_LIB_ID
.
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.
Variable Name | Semantics | Default | Notes |
---|---|---|---|
GCC_NO_ |
Suppress the |
true
|
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 |
NOCYGWIN_ |
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 be OK.
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_ID
variable 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):
make
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
in the
directory.
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