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

From: Valentin Samko (boost_at_[hidden])
Date: 2005-06-07 13:36:45

>> 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.

RR> Yes it is "compatible". Just build with:

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

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

Sorry, I did not describe the problem well enough.
I am talking about STLport compiled in debug mode (but without
__STL_DEBUG), linked against the debug version of native runtime.

STLport does not completely replace native runtime completely, new/delete/etc
from native c++ runtime are still used.

If we link software compiled in debug mode with STLport which uses
release mode of native runtime, we end up with several variants of
native runtime being used in the same process, which in some cases
leads to bugs (for example, if you allocate in debug heap and free in
release heap, or vice verse). I have also experienced link time
problems with this setup when linking statically, when both,
release and debug static runtime libraries were autolinked to the same
process, release one via STLport, and another debug one because we
compiled our project in debug mode.

So, there're three variants (unless we mix debug and release variants
of native runtime in the same process):
    1. Release variant of our code linked against release variant of STLport
    2. Debug variant of our code linked against debug variant of STLport.
    3. Debug variant of our code linked against debug variant of STLport, all compiled with __STL_DEBUG.

I understand that Boost only supports 1 and 3, and I would like
option 2 to be added. Currently in mode 2 we get
#            pragma message("warning: STLPort debug versions are built with /D_STLP_DEBUG=1")
#            error "Build options aren't compatible with pre-built libraries"

>> 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?

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

It is just that sometimes it is convinient to have executables which were not
updated/recompiled for a long time (compiled against an old version of STLport
ages ago) to be started from the same directory as a bunch of new programs,
which already use new the version of STLport.

It is good news if it is possible to change this. I agree that it makes
sense to wait until the next release. I am happy to patch our copy of
autolink locally, once we agree on this 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?

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

Good point, thanks.

--
Valentin Samko
http://val.samko.info