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

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

> We're just about ready to start moving the libstdc++ debug mode into 
> the FSF tree. There is a lot of code in the debug mode, so here's a 
> tentative plan to get things rolling. Comments are _always_ welcome.

This is excellent to see.  I will only comment on things I'd really
care about and/or could help fix/address before commit.

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

Regards,
Loren