This is the mail archive of the
mailing list for the libstdc++ project.
Re: [libstdc++ PATCH] libstdc++ debug mode
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: dgregor at apple dot com
- Date: Tue, 15 Jul 2003 04:57:02 -0500
- Subject: Re: [libstdc++ PATCH] libstdc++ debug mode
- References: <E608DE1C-B656-11D7-9E1F-00039354D67A@apple.com>
Some things to think about.
>When testing this patch, be sure to:
> 1) Apply the above-mentioned g++specs patch.
> 2) Rerun autoconf and automake in gcc/libstdc++-v3.
> 3) Pass "--enable-libstdcxx-debug" to configure
> 4) If running the libstdc++ testsuite, add the flag "-D_GLIBCXX_DEBUG"
>into the flags returned from --build_cxx in the script
For 4, You should just change
and in /libstdc++-v3/testsuite/testsuite_hooks.h change
the define of
>For those that don't want to apply the patch and rerun
>autoconf/automake, there's a patched gcc/libstdc++-v3 available here:
>Just extract it into a mainline CVS checkout just above the toplevel
>directory and it will overwrite your libstdc++-v3 directory with the
That's helpful, thanks. For some reason, stl_algo.h bits don't apply,
but the rest of the patch is fine (and the archive stl_algo.h can be
updated via cvs.)
>Tested on i686-pc-linux-gnu and powerpc-apple-darwin; no regressions on
>either platform in normal (release) mode or debug mode. ChangeLog
> * include/bits/gnu-cxx-utility.h: New.
Eh. For the time being, please just put the __is_null_pointer bits into
the string includes.
> * include/bits/debug/support.h: New.
> * include/bits/debug/vector.h: New.
> * include/ext/debug/bitset: New.
> * include/ext/debug/deque: New.
Please don't nest directories in here.
* include/debug: Add your stuff here.
like the ext directory duplicate headers.
> * debug/Makefile.am: New.
There's got to be a better solution than this. . . If you don't want to
keep the old, hacky src/Makefile.am rules, that is ok with me, but let's
try to come up with something that's an improvement that doesn't
duplicate so much of src/Makefile.am in the process. Alexandre Oliva
recently suggested looking at the multilib approach, which I believe
libjava uses: can you take a look at that approach please, or quiz him
to see what he means by this?