[MacPorts] #22112: Link error when linking with boost program options in the debug variant

[MacPorts]

#22112: Link error when linking with boost program options in the debug variant
--------------------------------+-------------------------------------------
 Reporter:  raphael@…           |       Owner:  nox@…           
     Type:  defect              |      Status:  new             
 Priority:  Normal              |   Milestone:                  
Component:  ports               |     Version:  1.8.1           
 Keywords:                      |        Port:  boost           
--------------------------------+-------------------------------------------

Comment(by 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
 [http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch30s03.html
 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.

-- 
Ticket URL: <http://trac.macports.org/ticket/22112#comment:2>
MacPorts <http://www.macports.org/>
Ports system for Mac OS