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