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
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
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
On Tuesday 07 June 2005 20:36, Valentin Samko wrote:
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"
AOL. We use a slightly patched 1.32 here (mostly so that it works with embedded Visual C++ cross compilers) and also fixed above issue, working with is without problems now. The final libnames need to be fixed, AFAIR, the rules for the naming are laid out in that file. To me it isn't even worth a warning.
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').
A totally different thing is the STLport version which in fact is giving me big headaches as STLport 5 dropped tags like the compiler name from their DLL name. So, no way to install STLport for different compilers alongside each other anymore. I tried to lobby for this feature but the voices against were stronger. Anyway, it needs to be taken into consideration. Uli
participants (3)
-
Rene Rivera -
Ulrich Eckhardt -
Valentin Samko