Boost logo

Boost :

From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-03-02 14:52:31

"John Maddock" <john_at_[hidden]> wrote in message
> > Currently, if you try to compile a program that uses boost::regex
> > boost versions 1.31 and 1.32) under the debug static runtime
> > library(libboost_regex-vc71-sgd-1_32.lib), you'll get a bunch of
> > defined symbols something like this:
> >
> > LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswlower already defined in
> > c_regex_traits.obj
> > and so on for all of the character type macros: _iswalpha _iswupper
> > _iswlower _iswdigit _iswxdigit _iswspace _iswpunct _iswalnum _iswprint
> > _iswgraph _iswcntrl _iswascii
> >
> > This has been noticed before && stems from the fact that the inline
> > directive is ignored for debug mode, causing those inline functions to
> > exist
> > both in the C runtime library and in the regex lib. I found a note going
> > back to 2002 -
> > - which
> > indicates that this problem is longstanding.
> I've been trying to reproduce this (again), but can't at present, can you
> more specific because linking with the static VC runtime definitely works
> for me. Are you defining _UNICODE when building the regex lib? If so can
> you try building the lib without _UNICODE defined and linking to that
> (defining _UNICODE basically has no effect as far as the regex internals
> concerned).

Sure. Lets start by playing "your version, my version".

bjam -v gives me:

D:\extra\bin>bjam -v
Boost.Jam Version 3.1.10. OS=NT.
   Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.
   Copyright 2001 David Turner.
   Copyright 2001-2004 David Abrahams.
   Copyright 2002-2004 Rene Rivera.

And I've got SP1 of the .NET 2003 compiler, which is actually a significant
change despite the minor version number - technically that'd be VC7.1, and
it shows up as "Version 7.1.3088" in the "About" box of Visual Studio.

Next, how did I build? Well, I'm using boost.jam to build this, as per the
installation instructions.

Appended below are the instructions that I wrote up when I did it. These are
the exact command lines I did, none of which define _UNICODE. They are also
pretty much the installation instructions from Now, I'm not
saying that _UNICODE doesn't get defined, simply that it isn't anything
concious that I did. It all boils down to:

1) get a "Visual Studio .NET 2003" command prompt
2) bjam "-sTOOLS=vc-7_1" "-sPYTHON_ROOT=d:\Python23" "-sPYTHON_VERSION=2.3"

PS. I took a look at my environment variables, and UNICODE isn't defined.

Finally, which precise library did I use? Well, that'd be multi-threaded,
static, debug.

Hope that helps.


Step 1: Downloaded boost_1_32_0 to a workarea
[d:\svn\code\thirdpty\boost\boost_1.32.0] corresponding to
Step 1.5:
  Imported the whole tree into Subversion before making any changes or
compiling anything:
  cd d:\svn\code\thirdpty\boost\boost_1.32.0
        svn import http://server/code/thirdpty/boost/boost_1.32.0 -m
"Initial import from"

Step 2:
  Downloaded bjam.exe executable (see

Step 3. Installed Python version 2.3 before building, so that we could get
the compiled python support.
Step 4 Patched the boost_1_32_0 source to get around the _iswalpha link

Step 5:
  in the directory extracted from the archive downloaded in step 1
  (making sure that the VC7.1 command line tools are selected (on my box I
  a command prompt icon called "Visual Studio .NET 2003 Command Prompt"
  by the visual studio instalation process) use bjam to build the libraries

   D:\boost\boost_1_32_0>bjam "-sTOOLS=vc-7_1" "-sPYTHON_ROOT=d:\Python23"
"-sPYTHON_VERSION=2.3" stage

> John.
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at