"John Maddock" <john@johnmaddock.co.uk> wrote in message news:03ba01c51f23$5ebf5100$81800252@fuji...
Currently, if you try to compile a program that uses boost::regex (either 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 multiply 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 be 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 are 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 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" stage 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 http://server/code/thirdpty/boost/boost_1.32.0. See http://www.boost.org/more/getting_started.html#Download 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 boost.org" Step 2: Downloaded bjam.exe executable (see http://www.boost.org/tools/build/jam_src/index.html) 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 issue 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 used a command prompt icon called "Visual Studio .NET 2003 Command Prompt" created 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: