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 -
> > http://lists.boost.org/MailArchives/boost-users/msg01398.php - 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
Sure. Lets start by playing "your version, my version".
bjam -v gives me:
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
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 boost.org. 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,
Hope that helps.
Step 1: Downloaded boost_1_32_0 to a workarea
[d:\svn\code\thirdpty\boost\boost_1.32.0] corresponding to
Imported the whole tree into Subversion before making any changes or
svn import http://server/code/thirdpty/boost/boost_1.32.0 -m
"Initial import from boost.org"
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
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"
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk