Re: Getting Apple's libstdc++ debug mode into the FSF tree

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

| > 5) g++specs to deal with -lstdc++-debug: this will be a small patch 
| > that teaches the driver to deal with the debug library. This is the 
| > only change to the compiler that will be absolutely required.
| 
| If there is a change in libraries rather than an extra library, I too
| would rather see a formal switch defined to control the selection.
| I.e. this would indeed mirror the almost portable, yet defined on
| per-port basis, -pthread flag.  Humm, I don't see the issue Benjamin
| raised since all ports get the same definition of the spec file bits
| for picking up libstdc++.
| 
| > 6) Debug-mode std::map patch: this will be another small patch that 
| > turns on replacement of std::map with the debug version when 
| > _GLIBCXX_DEBUG is defined.
| 
| I'd really be against any new code being installed in the C++ library
| which is keyed off a macro exposed to the user (_GLIBCXX_DEBUG).  We
| have been working hard to kill those regions.  I would not block such
| a change unless the implementations don't mix gracefully (even then,
| I'm only one vote of all the library implementators).  I.e. if the
| user compiles some code with _GLIBCXX_DEBUG and some without and the
| mixed code can crash, I'd be completely against the change.  I've read
| too many PRs from confused users over the years before we rectified
| the threading code situation...

I would suggest the activation of _GLIBCXX_DEBUG be automatically
supplied by the compiler, at the same time it is asked to use 
-lstdc++-debug.

-- Gaby