|
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.
You could achieve the same results by using the MinGW version of gcc, but the Cygwin compiler has two advantages:
--enable-languages=c,c++
to disable other languages which
fail to build properly.
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_
|
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 |
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.
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.
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.
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