Autolinking against debug STLport

[eckhardt@…]

I can't use autolinking with the following setup:

• using a debug build
• using STLport
• not using additional checks and diagnostics (_STLP_DEBUG)

The autolinking code should simply look for the "dp" variant of the Boost libraries. What I get is a warning that these libs are not built by default. Even worse, I get an error downright refusing to link with that version, even though I did compile them. However, that error is still better than nothing, because the macros defining the version are then set to "gdp" which is simply incompatible with my settings.

Things to fix:

• Fix the generated tags, i.e. replace "gdp" with "dp" for above example.
• Don't generate an error when using STLport with debug symbols but without additional diagnostic.

Further things that could be fixed, too:

• Don't output a warning unless lib diagnostics (BOOST_LIB_DIAGNOSTIC) are actually requested.
• Document the meaning of an 'n' in the generated tag.
• Remove redundant comment documenting the 'p' in the generated tag.
• Fix spelling of STLport here, without a capital P.
• Fix warnings, those claim that you should use "/D_STLP_DEBUG=1", but a simple "/D_STLP_DEBUG" is sufficient. A short grep shows that several other parts of Boost also have this, maybe creating separate ticket and patch would be a better choice for this.
• Fix indention of preprocessor commands, large parts use 3 spaces, some parts use 4.

Concerning the version, this bug is present in today's trunk, 1.43 and 1.33.1, which are also all versions I checked. Concerning 1.33.1, we are using a local version where this discrepancy is fixed and have not found any problems with it.

[eckhardt@…]

patch against trunk

[John Maddock]

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]

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.

[John Maddock]

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