|
Boost : |
From: Valentin Samko (boost_at_[hidden])
Date: 2005-06-06 17:52:19
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.
When I added this mode and recompiled boost, everything ran without
any noticeable problems. I think it is worth adding this mode to
boost build so that developers wouldn't have to patch boost build to
add this mode.
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?
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?
I understand that we could solve these problems either by not using
STLport, or by changing the way we use it, but unfortunately, this is
next to impossible for us, as we have a large software suite which is
built and supported this way for years. Also, I think other developers
would benefit if Boost provided workarounds/solutions for these common
STLport problems.
-- Valentin Samko http://val.samko.info
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk