Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. — Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is the documentation for an old version of boost. Click here for the latest Boost documentation.

C++ Boost

Boost.Build

gcc-nocygwin toolset

Introduction

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.

Configuration Variables

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_
EXPORT_ALL		 Suppress the --export-all-symbols linker flag. 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 (-sGCC_NO_EXPORT_ALL="")
NOCYGWIN_
STLPORT_LIB_ID		 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


Prerequisites

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.

STLport iostream support

Here's the procedure for using the STLport iostream libraries with gcc-nocygwin:

  1. Build the iostream libraries with no cygwin1.dll dependencies.
  2. Set the NOCYGWIN_STLPORT_LIB_ID variable to the library base name (e.g. stlport_cygwin)
  3. Configure necessary variables for the gcc-stlport toolset


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 -f gcc-cygwin.mak CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin" DYN_LINK="g++ -shared -mno-cygwin -o"

You may get some errors for missing include files like ../include/time.h. 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 ln -s mingw include 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 ../g++-v3/ctime. The libstdc++ directory is probably something like /usr/include/c++/3.2, in which case you would use ln -s 3.2 g++-v3 in the /usr/include/c++ directory.

Toolset limitations

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