Re: [boost] STLport builds (and boost.thread)

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-06-07 10:38:39

Valentin Samko wrote:
> I've been trying to build Boost.Thread and a number of other libraries
> for use in the software in the company where I work, and was only stopped
> by a number of STLport related problems. We already use header-only boost
> libraries for many years, and now would like to start using other
> boost libs.
> 
> The main problems are:
> 
> 1. We use unchecked STLport variant (i.e. without __STL_DEBUG).
>    Unfortunately, Boost is not compatible with this mode, although
>    a fix to add this mode is only a few lines of code in boost build.

Yes it is "compatible". Just build with:

        bjam "-sBUILD=<runtime-build>release"

Which tells it to use the non-debug version of the library runtime, 
STLPort in your case.

> 2. It is very usefull that compiled boost libraries embed version
>    number and different compile time options in their names.
>    Unfortunately, STLport version is not embedded in their names (only 'p').
> 
>    This creates a problem where two executables compiled against different
>    STLport versions try to use the same Boost.WhateverLibrary dll.
> 
>    Are there any reasons not to embed STLport version number into boost
>    library names?

No reasons other than it hasn't come up until now. Most people aren't 
creating programs that use multiple versions of STLport. I'm not going 
to change it now though. As there's just not enough time before release 
to test changes to the autolink code. So it's going to have to be an 
after 1.33 change.

> 3. A separate issue with Boost.Threads, where _sntprintf is called in
>    boost_error in read_write_mutex.cpp, even when building with STLport,
>    which does not have _snprintf. Also, there is bug in boost_error, which
>    wrongly assumes that _sntprintf zero terminates the resulting string. I
>    also wrote a patch to fix this problem. Is there any way to merge
>    it into Boost.Thread?

You should post such questions with some indication in the subject line 
so that the library author notices. (as I'm doing to this reply)

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org