From b927e74714689722da0618bf32f368efbee59236 Mon Sep 17 00:00:00 2001 From: Raoul Gough Date: Fri, 24 Jan 2003 21:39:59 +0000 Subject: [PATCH] Use updated Cygwin g++ support for -mno-cygwin [SVN r17038] --- gcc-nocygwin-tools.html | 295 +++++++++++++++++-------------------- gcc-nocygwin-tools.jam | 84 +++-------- v1/gcc-nocygwin-tools.html | 295 +++++++++++++++++-------------------- v1/gcc-nocygwin-tools.jam | 84 +++-------- 4 files changed, 312 insertions(+), 446 deletions(-) diff --git a/gcc-nocygwin-tools.html b/gcc-nocygwin-tools.html index 4495592b5..43e486398 100644 --- a/gcc-nocygwin-tools.html +++ b/gcc-nocygwin-tools.html @@ -28,206 +28,189 @@

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. +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.

-

-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. -
+

+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

-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 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.

-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. -

+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 DefaultNotesNotes
+ GCC_NO_
EXPORT_ALL + 		- NOCYGWIN_
STLPORT_
LIB_ID + Suppress the --export-all-symbols linker flag. 		+ true + - The name used to generate the stlport library names (corresponding - to the LIB_BASENAME variable in the STLport make files). + 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 + 		- mingw32 + Use the STLport standard + library instead of gcc's own library. + empty + - This forms the middle part of the STLport library - names, for example libstlport_mingw32_debug.a + 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

-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. +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.

-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. +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.

-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. +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.

-

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). +

STLport iostream support

-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. +Here's the procedure for using the STLport iostream libraries with +gcc-nocygwin: + +

+

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

+

+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. +

+ +

-Toolset and docs contributed May 2002 by -Raoul Gough +Written May 2002 and revised January 2003 by Raoul Gough

diff --git a/gcc-nocygwin-tools.jam b/gcc-nocygwin-tools.jam index 2a9479186..131d430a1 100644 --- a/gcc-nocygwin-tools.jam +++ b/gcc-nocygwin-tools.jam @@ -1,4 +1,4 @@ -# (C) Copyright David Abrahams and Carlos Pinto Coelho 2001, 2002. +# (C) Copyright Raoul Gough, 2002, 2003. # Permission to copy, use, modify, sell and distribute this software # is granted provided this copyright notice appears in all # copies. This software is provided "as is" without express or implied @@ -9,75 +9,25 @@ # # This toolset builds boost on a cygwin system using the -mno-cygwin # gcc option, which creates windows-native binaries (without any -# dependencies on cygwin1.dll). It requires an STLport built -# by mingw gcc, or maybe by cygwin gcc using the -mno-cygwin -# option, if you feel like messing with the STLport makefiles. -# -# Configuration: -# -# You need a boost jam executable that was built for NT, not -# cygwin. There are two reasons for this. Firstly, you need the -# NT jam variable to be set, and secondly, the cygwin build of -# boost jam executes commands via the cygwin shell, which doesn't -# handle backslashes in pathnames properly. -# -# Don't forget to set STLPORT_ROOT, either in your environment -# or in Jamrules in the boost installation directory. Also set -# BOOST_ROOT. Use native windows path names and not the -# /cygdrive/... style. -# -# Set NOCYGWIN_STLPORT_LIB_ID to set the STLport naming -# convention (default is "mingw32" which looks for libraries -# named like stlport_mingw32_stldebug.lib) -# -# Run boost jam from the boost install directory like this: -# -# jam -sTOOLS=gcc-nocygwin -# -# If things are going wrong, a handy jam option is -d2, which shows -# commands before execution. +# dependencies on cygwin1.dll). It should "just work" if your +# Cygwin gcc installation is up to date (since October 2002). +# Basically, if std::cout << "Hello world" works with +# g++ -mno-cygwin, you should be alright. # -NOCYGWIN_STLPORT_LIB_ID ?= mingw32 ; +# Check STLport support (backwards compatability) +if $(NOCYGWIN_STLPORT_LIB_ID) { + local GCC_STLPORT_LIB_ID = $(NOCYGWIN_STLPORT_LIB_ID) ; -{ - local GCC_STLPORT_LIB_ID = $(NOCYGWIN_STLPORT_LIB_ID) ; - - extends-toolset gcc-stlport ; + extends-toolset gcc-stlport ; +} +else { + extends-toolset gcc ; } -flags gcc-nocygwin CFLAGS : -mno-cygwin ; -flags gcc-nocygwin LINKFLAGS : -mno-cygwin ; -flags gcc-nocygwin LINKFLAGS multi : -mthreads ; +# Prefer linking DLLs without the -Wl,--export-all-symbols flag +GCC_NO_EXPORT_ALL ?= true ; -#### Link #### - -# -# Duplicated from gcc-tools.jam (unfortunately) because we don't want -# IMPLIB_COMMAND to include -Wl,--export-all-symbols -# - -rule Link-action -{ - SPACE on $(<) = " " ; - # if we don't have a GNU linker then we can't pass any GNU-ld specific flags: - if $(NO_GNU_LN) - { - LNOPT on $(<) = ; - } - else - { - LNOPT on $(<) = "" ; - } - - OUTTAG on $(<) = "" ; - SOTAG on $(<) = ; - ACTION_1 on $(<) = ; - - # This will appear before the import library name when building a DLL, but - # will be "multiplied away" otherwise. - IMPLIB_COMMAND on $(<) = "-Wl,--exclude-symbols,_bss_end__:_bss_start__:_data_end__:_data_start__ -Wl,--out-implib," ; - DEPENDS $(<) : $(NEEDLIBS) ; - gRUN_LD_LIBRARY_PATH($(<)) += $(GCC_STDLIB_DIRECTORY) ; - gcc-Link-action $(<) : $(>) ; -} +# Use the -mno-cygwin flag for compiling C, C++ and linking +CFLAGS += -mno-cygwin ; +LINKFLAGS += -mno-cygwin ; diff --git a/v1/gcc-nocygwin-tools.html b/v1/gcc-nocygwin-tools.html index 4495592b5..43e486398 100644 --- a/v1/gcc-nocygwin-tools.html +++ b/v1/gcc-nocygwin-tools.html @@ -28,206 +28,189 @@

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. +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.

-

-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. -
+

+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

-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 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.

-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. -

+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 DefaultNotesNotes
+ GCC_NO_
EXPORT_ALL + 		- NOCYGWIN_
STLPORT_
LIB_ID + Suppress the --export-all-symbols linker flag. 		+ true + - The name used to generate the stlport library names (corresponding - to the LIB_BASENAME variable in the STLport make files). + 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 + 		- mingw32 + Use the STLport standard + library instead of gcc's own library. + empty + - This forms the middle part of the STLport library - names, for example libstlport_mingw32_debug.a + 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

-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. +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.

-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. +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.

-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. +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.

-

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). +

STLport iostream support

-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. +Here's the procedure for using the STLport iostream libraries with +gcc-nocygwin: + +

+

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

+

+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. +

+ +

-Toolset and docs contributed May 2002 by -Raoul Gough +Written May 2002 and revised January 2003 by Raoul Gough

diff --git a/v1/gcc-nocygwin-tools.jam b/v1/gcc-nocygwin-tools.jam index 2a9479186..131d430a1 100644 --- a/v1/gcc-nocygwin-tools.jam +++ b/v1/gcc-nocygwin-tools.jam @@ -1,4 +1,4 @@ -# (C) Copyright David Abrahams and Carlos Pinto Coelho 2001, 2002. +# (C) Copyright Raoul Gough, 2002, 2003. # Permission to copy, use, modify, sell and distribute this software # is granted provided this copyright notice appears in all # copies. This software is provided "as is" without express or implied @@ -9,75 +9,25 @@ # # This toolset builds boost on a cygwin system using the -mno-cygwin # gcc option, which creates windows-native binaries (without any -# dependencies on cygwin1.dll). It requires an STLport built -# by mingw gcc, or maybe by cygwin gcc using the -mno-cygwin -# option, if you feel like messing with the STLport makefiles. -# -# Configuration: -# -# You need a boost jam executable that was built for NT, not -# cygwin. There are two reasons for this. Firstly, you need the -# NT jam variable to be set, and secondly, the cygwin build of -# boost jam executes commands via the cygwin shell, which doesn't -# handle backslashes in pathnames properly. -# -# Don't forget to set STLPORT_ROOT, either in your environment -# or in Jamrules in the boost installation directory. Also set -# BOOST_ROOT. Use native windows path names and not the -# /cygdrive/... style. -# -# Set NOCYGWIN_STLPORT_LIB_ID to set the STLport naming -# convention (default is "mingw32" which looks for libraries -# named like stlport_mingw32_stldebug.lib) -# -# Run boost jam from the boost install directory like this: -# -# jam -sTOOLS=gcc-nocygwin -# -# If things are going wrong, a handy jam option is -d2, which shows -# commands before execution. +# dependencies on cygwin1.dll). It should "just work" if your +# Cygwin gcc installation is up to date (since October 2002). +# Basically, if std::cout << "Hello world" works with +# g++ -mno-cygwin, you should be alright. # -NOCYGWIN_STLPORT_LIB_ID ?= mingw32 ; +# Check STLport support (backwards compatability) +if $(NOCYGWIN_STLPORT_LIB_ID) { + local GCC_STLPORT_LIB_ID = $(NOCYGWIN_STLPORT_LIB_ID) ; -{ - local GCC_STLPORT_LIB_ID = $(NOCYGWIN_STLPORT_LIB_ID) ; - - extends-toolset gcc-stlport ; + extends-toolset gcc-stlport ; +} +else { + extends-toolset gcc ; } -flags gcc-nocygwin CFLAGS : -mno-cygwin ; -flags gcc-nocygwin LINKFLAGS : -mno-cygwin ; -flags gcc-nocygwin LINKFLAGS multi : -mthreads ; +# Prefer linking DLLs without the -Wl,--export-all-symbols flag +GCC_NO_EXPORT_ALL ?= true ; -#### Link #### - -# -# Duplicated from gcc-tools.jam (unfortunately) because we don't want -# IMPLIB_COMMAND to include -Wl,--export-all-symbols -# - -rule Link-action -{ - SPACE on $(<) = " " ; - # if we don't have a GNU linker then we can't pass any GNU-ld specific flags: - if $(NO_GNU_LN) - { - LNOPT on $(<) = ; - } - else - { - LNOPT on $(<) = "" ; - } - - OUTTAG on $(<) = "" ; - SOTAG on $(<) = ; - ACTION_1 on $(<) = ; - - # This will appear before the import library name when building a DLL, but - # will be "multiplied away" otherwise. - IMPLIB_COMMAND on $(<) = "-Wl,--exclude-symbols,_bss_end__:_bss_start__:_data_end__:_data_start__ -Wl,--out-implib," ; - DEPENDS $(<) : $(NEEDLIBS) ; - gRUN_LD_LIBRARY_PATH($(<)) += $(GCC_STDLIB_DIRECTORY) ; - gcc-Link-action $(<) : $(>) ; -} +# Use the -mno-cygwin flag for compiling C, C++ and linking +CFLAGS += -mno-cygwin ; +LINKFLAGS += -mno-cygwin ;