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.

You could achieve the same results by using the MinGW version of gcc, but the Cygwin compiler has two advantages:

  1. It can build for both environments - Unix emulation and Windows native - with one compiler.
  2. You can use the latest versions of GCC. The latest released version of MinGW GCC is 2.95.3, and building MinGW-specific versions of GCC 3.0.x has proven to be quite difficult. However, it's straightforward under Cygwin. Just be sure to configure with --enable-languages=c,c++ to disable other languages which fail to build properly.

Configuration Variables

The gcc toolset responds to the variables shown in the following table, which can be set in the environment or configured on the jam command-line using -sVARIABLE_NAME=value.

This toolset is an extension to the gcc-stlport toolset and therefore also responds to all of the configuration variables for gcc-stlport and gcc in addition to those listed below.

Variable Name Semantics Default Notes
NOCYGWIN_
STLPORT_
LIB_ID
The name used to generate the stlport library names (corresponding to the LIB_BASENAME variable in the STLport make files). mingw32 This forms the middle part of the STLport library names, for example libstlport_mingw32_debug.a

Prerequisites

Obviously, you'll need Cygwin installed on your Windows system. Earlier releases of Cygwin came as monolithic packages, but this switched to individually selectable components around 2000. If you've got a recent installation, you'll have to make sure you've got the optional mingw-runtime package installed. Have a look in /lib/mingw to see if things like libmingw32.a and libcrtdll.a are present, and that the directory /usr/include/mingw includes the standard headers stdio.h etc. Install the additional package if necessary.

You will also need the STLport standard library installed and fully compiled (i.e. using its own iostreams) without any Cygwin dependencies. This would be very easy if you had the real mingw compiler installed, because the STLport distribution includes a ready-made makefile for this, called gcc-mingw.mak. Making this work with the Cygwin compiler requires a couple of changes to the file (see below for details). Sooner or later there may be a specific nocygwin makefile for STLport which will make this easier.

Finally, you will need a Boost jam executable that was built for Windows (aka NT). The Cygwin-built Boost jam is not suitable, primarily because it executes commands via the Cygwin shell, which doesn't handle backslashes in Windows pathnames. Until there is a specific nocygwin makefile for Boost jam, it is probably best to download the prebuilt executable for Windows.

Building with gcc-nocygwin

Refer to the gcc-stlport configuration section for details of the STLPORT_ROOT variable, which you'll have to configure (at the very least). Make sure to use Windows-style pathnames and not the /cygdrive/x/... style (you're using the Windows native Boost jam, remember).

Configure additional variables as described here if you want to build the Boost.Python library, making sure to point it at a Windows installation of Python and not a Cygwin one. At the time of writing, the Python example simple_vector.cpp fails to compile in debug mode because of an incompatability with the STLport debugging STL containers, but everything else should build properly.

If your STLport libraries don't have names like stlport_mingw32… you will need to set the environment variable NOCYGWIN_STLPORT_LIB_ID to replace the "mingw32" part of the library names.

Once your environment is right, you can start the build as for any other toolset, using the toolset name "gcc-nocygwin". If you want to see exactly what's going on, try supplying jam the -d2 option to show the raw commands as they execute.

If you work with COM or DirectX, you will want to force gcc to generate vtable-thunks by including <vtable-thunks>on in the BUILD global variable. If you're messing around with this stuff, make extra sure that you build all your libraries (including STLport) with the same vtable style.

Boost threads library and gcc 2.95.3-5

The Cygwin-special gcc release 2.95.3-5 does not include a thread-safe version of libgcc.a, which prevents any of it's code being thread-safe, even with the -mthreads option. If you're feeling lucky, grafting in the thread-safe versions of _eh.o and frame.o from the mingw 2.95.3 libgcc.a seems to fix the problem (give the hybrid library a new name and adjust the compiler's specs file appropriately). Later releases of the Cygwin compiler probably won't suffer from this restriction, so you should definitely upgrade if you want to use the threads library.

Building a native STLport with Cygwin gcc

The current release (4.5.3) of STLport does not include an extra makefile to build the libraries with the -mno-cygwin mode of Cygwin gcc, but you can use the existing gcc-mingw.mak file by setting the CXXFLAGS_COMMON variable on your make command line, as follows:

make -fgcc-mingw.mak "CXXFLAGS_COMMON=-mno-cygwin -I/usr/include/mingw"
You might also need to add -mthreads and/or -fvtable-thunks within the quotes, depending on what kind of executables you ultimately want to produce. You can create multiple versions of the libraries by setting a different LIB_BASENAME in each case, and set up a corresponding value in the NOCYGWIN_STLPORT_LIB_ID shell variable before building Boost.

If you have built a newer version of Cygwin GCC from source, or you've built an older one and configured it with --prefix=, you'll need to add the following DYN_LINK variable setting in order to get the GCC support libraries into the library search path when the STLPort DLLs are built:

"DYN_LINK=c++ -shared -L/usr/local/lib -o"
(substitute the path you passed to --prefix= for /usr/local/lib if you are using a non-standard configuration).

Make sure that you're really compiling the STLport iostreams instead of just wrapping the Cygwin gcc streams. The default behaviour for STLport 4.x is correct, but it is possible to reconfigure this manually. Refer to the documentation on selecting the IOStreams mode if you're in doubt.

Toolset and docs contributed May 2002 by Raoul Gough