Boost C++ Libraries: Ticket #4349: Autolinking against debug STLport

attachment set

eckhardt@… — Wed, 16 Jun 2010 10:58:21 GMT

attachment → boost-trunk-autolinking.0.patch

patch against trunk

status changed; resolution set

John Maddock — Sat, 24 Jul 2010 17:15:27 GMT

status new → closed
resolution → invalid

Unfortunately your patch would break a lot of other things, and in general this is actually unfixable.

Assuming you built with something like:

bjam stdlib=stlport runtime-debugging=off

Then you do indeed get libraries with a -dp suffix. Note however that these would have been built with the /MD compiler option and linked against stlport-5.2.lib and not against the debug libraries (stlportd-5.2.lib) which would require building with /MDd - this latter option is simply not supported by Boost.Build as far as I can see, which is why the auto-linking code gives the error message it does.

Now here's the issue - the libraries built with a -dp suffix can only be safely used if your code is also built with /MD and does not define _DEBUG (since the latter is used by MS to indicate the /MDd compiler option). In other words there is no way to select the "correct" -dp libraries in this case, although it will select a different -p variant without debugging info that is binary compatible with /MD.

To get the error message that you did, I assume that you built your code with /MDd which will produce an error - and quite right too - as there is no way for Boost.Build to create those binaries (/MDd without _STLP_DEBUG). Further, building with /MDd and linking against -dp binaries is actually dangerous, as you're linking code built with two different MSVC runtimes, and two different STLport binaries.

Anyway, I hope I've got that all correct - this is fiendishly complex to figure out which is why we created auto_link.hpp in the first place!

Ulrich Eckhardt — Sun, 25 Jul 2010 06:42:12 GMT

I guess my misunderstanding was that there are 'd' and 'g', which mean the same thing but one for the program being built and the other for the support libraries it uses. What I thought was that the 'g' was only intended to activate additional diagnostics (checked iterators etc). Looking at the docs for this makes it a bit clearer, even though these docs refer to an undocumented 'n' flag in the example, too. How about something like this concerning the documentation

g debug/diagnostic runtime libraries (release if not present).
y debug/diagnostic Python runtime (release if not present).
d debug/diagnostic build (release if not present).

The above makes clearer that the three all control the same thing but for separate parts of the code.

What I'm wondering though is why that separation exists. I personally haven't seen the need to use different settings for the program being built and the libraries it links. Worse, MSVC assumes you don't want to do that either. What I do want now and then is to disable additional diagnostics, because those tend to slow down things a lot, especially on remotely-debugged embedded targets, which is what I work with most.

status, component changed; resolution deleted

John Maddock — Sun, 25 Jul 2010 09:58:26 GMT

status closed → reopened
resolution invalid
component config → Getting Started Guide

You're correct that for msvc the g and d options should always be used together, however, Boost.Build is compiler and platform independent, and for some compilers there is a clear separation between these two. Others simply don't have a notion of "runtime-debugging" and so the g option is never used.

Reassigning to the getting started guide maintainers...

owner, status changed

John Maddock — Sun, 25 Jul 2010 09:58:56 GMT

owner changed from John Maddock to Dave Abrahams
status reopened → new