Link error when linking with boost program options in the debug variant

[raphael@…]

The current approach of supporting debugging iterators in the +debug variant of boost (see #20478) has a drawback: You get a linker error if you try to link some program that was compiled without -D_GLIBCXX_DEBUG (i. e. without debugging iterators) with the boost program options library compiled with the +debug variant. This is the case for both the normal library libboost_program_options-mt.dylib and the debugging library libboost_program_options-mt-d.dylib.

I propose to add a new variant for debugging iterators and remove define=_GLIBCXX_DEBUG from the +debug variant.

[arsptr@…]

I'm seeing a similar problem which seems to have the same underlying cause.

It's pretty easy to describe. With boost built with the debug option, you can get get malloc errors simply by linking against one of the boost libraries, even if your code doesn't call boost at all. Consider:

#include <iostream>
#include <sstream>

int main()
{
    std::ostringstream str;;
    str << "All good!";

    std::cout << str.str() << std::endl;

    return 0;
}

Compiles, links and runs just fine:

% g++ -ggdb -o streamtest_good streamtest.cpp && ./streamtest_good
All good!

Now if we link against a boost library it all goes pear-shaped:

% g++ -ggdb -o streamtest_bad -L/opt/local/lib -lboost_program_options-mt \
    streamtest.cpp && ./streamtest_bad
streamtest_bad(8625) malloc: *** error for object 0x7fff70099500: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
zsh: abort      ./streamtest_bad

The problem is that the boost library is compiled with _GLIBCXX_DEBUG defined, and this REQUIRES that programs that link against it also define the same symbol. If we do, it all works again:

% g++ -ggdb -o streamtest_fixed -L/opt/local/lib -lboost_unit_test_framework-mt-d \
    -D_GLIBCXX_DEBUG streamtest.cpp && ./streamtest_fixed
All good!

I have spent an embarassing amount of time chasing this down, but basically the problem seems to come down to the Portfile, which defines _GLIBCXX_DEBUG. As noted in the ​documentation, this flag breaks binary compatibility.

variant debug description {Build debug libraries} {
    build.args-append   variant=debug,release define=_GLIBCXX_DEBUG
}

(I am not an expert in BJam build rules, but isn't this defining _GLIBCXX_DEBUG for release variants as well as debug? Substituting the non-debug libraries in the above test cases yields the same behaviour)

Anyway enabling the _GLIBCXX_DEBUG symbol here is probably the wrong thing to do, at least not without big flashing warnings so that users can also enable it in their code. Just for safety I'd prefer to back it out entirely.

[nox@…]

_GLIBCXX_DEBUG symbol removed in r60830