This is the mail archive of the
mailing list for the libstdc++ project.
Re: Getting Apple's libstdc++ debug mode into the FSF tree
On Tuesday, July 15, 2003, at 9:00PM, Loren James Rittle wrote:
Please note that your usage looks like that covered by multilibs. If
so, the option name must start with `-m' AFAIK. We have resisted
multilibing libstdc++-v3 over the years by making sure that all new
features and updating of old features which were keyed by macros allow
mix-n-matching at link time without introducing hard-to-debug crashes.
I don't know if multilibing addresses the next issue I will now raise.
Unfortunately, mix-n-match at link time is _very_ hard to support for
this problem, because the size of library-defined types (e.g.,
std::basic_string<...>) changes between debug and production mode.
std::basic_string is especially problematic because it is used in many
parts of the library. The real killers are compiled virtual functions
that return std::basic_string<> instances, such as
std::collate<char>::do_transform. Here we have:
1) A function instantiated in libstdc++, so it code cannot change at
all between debug and release mode.
2) A return type that changes size between debug and release mode.
3) A virtual function, so users must be able to duplicate the exact
I've made several attempts at mix-and-match linking, none of which has
been able to handle this particular case. I've more recently been
considering if it is worth providing a 90% debugging solution that does
allow mix-n-match linking, because the feature is so often requested.
Some ideas (some practiced, some not):
(1) An external reference to either name A or name B is inserted into
each C++ object file which included any C++ header where it matters
based on presence of macro. A is only defined in production
libstdc++. B is only defined in debug libstdc++. Both names are in
our library implementation namespace.
Unless through some trickery, both libraries get linked in. This is
actually quite likely, I think, so we should avoid this option.
(2) An external symbol reference that changes size based on presence
of your macro. The correctly keyed match is present in the related
We're probably stuck with this option :(
(3) What we did for threading support in the library (here we pay a
small price to use the indirection provided by the gthr abstraction
layer and its dynamic decision of when to use the mutex).
This would be very expensive for the debug mode, because release-mode
objects would have to be large enough to store the extra data required
in debug mode. For instance, a vector iterator in release mode is
generally 4 bytes, but in debug mode it jumps to 20 bytes.
(4) (For grins, I include:) Implement Plan 9 header/linker semantics
in GNU ld and all other linkers ever used with gcc. That was quite an