Re: msvc-stlport toolset linking to wrong runtime?

From: gbmvdd (grebe_at_[hidden])
Date: 2004-06-30 10:08:25

--- In jamboost_at_[hidden], David Abrahams <dave_at_b...> wrote:
> "gbmvdd" <grebe_at_b...> writes:
> 
> >
> > LIBCMTD.lib(dosmap.obj) : error LNK2005: __dosmaperr already
> > defined in LIBCD.lib(dosmap.obj)
> >
> > Closer investigation revealed that the above unit test framework 
> > library's object files contain a /DEFAULTLIB:LIBCMTD.lib where I 
> > think it should be LIBCD.lib. Can anyone shed any light on why 
that 
> > might be? It suggests to me that bjam is telling the 
compiler /MTd 
> > when it should be told /MLd, but I can't figure out why that 
would be 
> > happening.
> 
> You can verify or refute your theory by passing "-n -a" to your bjam
> invocation to see all of the commands it uses in the build.
> 
> -- 
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com

I tried your suggestion and found I was right. Invoking bjam again 
with -d 5 led me to the file

tools\build\v1\msvc-stlport-tools.jam

which contains this:

{
# This is simply an extension to the msvc toolset. However,
# STLPort doesn't have any single-threaded builds, so we're going
# to force all such targets to be built with multithread support.
# This is essentially a usage-requirement on the stlport library.
local gBUILD_PROPERTIES = [ difference $(gBUILD_PROPERTIES) : 
<threading>single ] <threading>multi ;
extends-toolset msvc ;
}

I think that explains everything. Obviously I have no choice but to 
link with the multithreaded C runtime. It took me a while to track 
down though. As it stands, specifying -sTOOLS=msvc-stlport and 
<threading>single generates libs without -mt in their names but which 
require a multi-threaded runtime nonetheless. A warning or error 
instead might be more helpful :)

Thanks for your help,
George