libcwd-1.0.4

	Support for libc-2.10.

	Bug fixes:

	Some obscure bug with the internal rwlock_tct.

libcwd-1.0.3

	Undocumented support for a 'backtrace_hook' function. The hook is
	called (if set) whenever memory is allocated, passing the current
	backtrace.

	Bug fixes:

        Patch by Joel Nordell to avoid a stack overflow in ~dm_alloc_copy_ct()
        in the case that all M_next objects in the chain is a very long list.

	Fixed a bug that could crash while accessing a (deleted) memblk_map_ct.

libcwd-1.0.0

	Fixed problems that stopped libcwd from working on sparc64.
	Thanks to Dennis Gilmore for giving me an account on his sparc64.

	Bug fixes:

	pthread_mutexattr_t objects were not initialized, resulting
	in undefined behaviour (libcwd_r only). I think this is what
	caused my previous problems with gcc-3.3.x. So, that version
	is supported again (this version of libcwd is tested to work
	again with 3.3.6).
	Fixed parallel build; make -j N now works.
	Fixed --disable-pch and --disable-alloc (broken since 0.99.47).
	Fixed --enable-debugt on amd64.

libcwd-0.99.47

	Added support for x86_64 / ELF64.

libcwd-0.99.46

        Libcwd now can be compiled with -D_GLIBCXX_DEBUG by passing
	--enable-glibcxx-debug during configuration.

	Bug fixes:

        When not using redzones (though still using magic numbers around
	allocations of course), allocation of not a multiple times
	sizeof(size_t) lacked the overflow test for the few bytes needed
	to align again to a mutliple of size_t. For example, if you'd
	allocate 9 bytes, then bytes 10, 11 and 12 were not checked for
	an overflow.

libcwd-0.99.45

	Support for libbfd (--enable-libbfd) has been entirely
	removed. There is a problem with the initialization;
	libcwd code is executed very early, before libbfd is
	initialized. The call to bfd_openr returns an
	uninitialized bfd structure...

	Debug symbols are now read from .debug/ or /usr/lib/debug
	when it is found that the real library is stripped.

	The CVS repository was converted to SVN. See README.SVN
	on how to get the latest alpha release.

	Bug fixes:

	Several compile bug fixes for FreeBSD.
	--disable-location was fixed.
	Libcwd would segfault if the application is linked with
	with -ldl left of -lcwd because then it can't find the
	correct dlopen (with dlsym(RTLD_NEXT, "dlopen")). Now it
	prints an error message about this and aborts.
	Several debian specific problems have been fixed (I am
	using debian myself now).

libcwd-0.99.44

	Allocated memory (operator new/new[], malloc/calloc/realloc)
	now can be extended with 'redzones'. The foot print of
	allocated memory will look as follows:

	pointer returned -->  +------------------------+
	by libc's malloc      |  magic number          |
	                      +------------------------+
			      |  size                  |
			      +------------------------+
			      |                        |
			      |       RED ZONE         |
			      |                        |
	pointer returned -->  +------------------------+
	to the application    |                        |
	                      |  Application space     |
                              ~                        ~
			      |                        |
			      +------------------------+
			      |                        |
			      |       RED ZONE         |
			      |                        |
			      +------------------------+
			      |  magic number          |
			      |________________________|

	The 'size' is the size of the application space
	(the requested space), incremented by a few bytes,
	if necessary, to align it to a multiple times size_t,
	and then increment that same amount again (not
	that you're supposed to access that value anyway).
	'size' and 'magic number' are size_t. The first red
	zone has a size such that the the difference between
	the pointer returned by libc's malloc and the pointer
	returned to the application is a multiple times 8
	bytes (the alignment garanteed by glibc's malloc).
	The redzone at the end has the same size incremented
	by a few bytes, if necessary, to align the last magic
	number to a sizeof(size_t) boundary. The pre- and post-
	redzones are filled with two different characters.
	At the moment a memory block is freed, these values
	are tested.
	You can chose the size of the redzone (default is 0)
	with the configure option --with-redzone=x in bytes.
	The real size will likely be larger because of the
	alignment constrains.

	Libcwd now uses cwautomacros: in order to build it
	from CVS you need to download and install cwautomacros
	from http://cwautomacros.berlios.de/

	Bug fixes:

	BlockList::uninitialize() accessed a struct that it just
	deleted, with a possible core dump as result. Fortunately,
	this bug wasn't too serious, because this function is
	only called as part of the global deinitialization
	of the application, after leaving main or calling exit.

        Calling dlopen for a library that is already linked
	the normal way would terminate the program (thinking
	two different shared libraries overlapped). Libcwd
	now properly 'ignores' such load attempts.

libcwd-0.99.43

	Bug fixes:

	It was still possible that unnamed 'shared libraries' that are
	mapped and listed in the dl_loaded list caused libcwd to crash
	with the error:
	FATAL  : std::ifstream.open(""): ENOENT (No such file or directory)
	I thought this was fixed in 0.99.38, but there was another place
	in the source where a test for this case was needed.

	Several serious bugs have been fixed related to the calculation
	of the load address of a shared library. A problem was that
	a load address returned by the dynamic linker of zero was
	treated as 'unknown' (falling back to more heuristic methods
	in that case). However, it turns out that on some machines,
	sometimes, system libraries are loaded "at" address 0. Avoiding
	overlaps between libraries in this case is done by having
	some 'empty' section at the beginning of the shared object
	that gives the library it's required offset, instead of loading
	each library at a different address (this only works when
	all those libraries have such empty sections that are 'tuned'
	in size to be compatible with one another). Apparently, this
	only works as a 'hint' for the dynamic linker, because it can
	still put the real image somewhere else in memory, possibly even
	with a negative 'load address'. This method was so different
	from how it worked on my system that libcwd totally messed up.
	On top of that, libcwd used the FILE offset to calculate the
	start of a section in memory, instead of the 'memory image'
	offset of the section (the VMA). That worked on my machine
	because all executable sections are at the start of the the
	shared library, so that the vma and the file offset were
	equal (with the exception of the executable, but libcwd made
	a special exception for that case). Blame this on the extremely
	bad availability of documentation on how dynamic linkers work.
	Anyway, thanks to an american soldier, who let me login on
	his laptop, via an ppp-over-ssh tunnel to get around the
	firewall for their army base in Irak (how exciting, and all
	that via a satelite link into the desert, of course), I've
	been finally able to debug on a machine that used this different
	way of linking and finally understand what VMA really is ;).
	Note that this also means that there is a huge difference
	between the load address of a shared library and the first
	(lowest) address that can actually be part of executable
	code of that library, something that was already fixed for
	the executable on 0.99.41 -- now also for all other shared
	objects.

	There was a missing colon between the mangled function name
	and the demangled function name (using a filter that printed
	both) in the allocated memory overview.

	Libcwd's new allocator got a face lift. It had some problems
	with large numbers of requested chunks due to two linear list
	searches over allocated memory blocks (even though each block
	is 8192 bytes, in some cases several thousand blocks are needed,
	making those linear searches rather slow). The current
	implementation is even faster than the allocator of libstdc++
	(constant allocation and deallocation times for any ammount
	allocated chunks).

libcwd-0.99.42

	Bug fixes:

	Compile warning for unused 'a1' and 'a2' in private_allocator.h
	was fixed (only needed for g++-4.x).

libcwd-0.99.41

	Bug fixes:

	Although the 'load address', relative to which ELF32 symbols
	are given, is 0 for the main executable, it doesn't have to
	be the REAL load address.  It turned out that it is possible
	that shared libraries are loaded into memory BELOW the
	executable. This resulted in a problem when the executable
	dynamically loads a library in this low region: a symbol
	look up for shared libraries that are loaded later was thought
	to be part of the executable and not resolved correctly.
	The 'start' of the executable is now set to be the start
	address of the first function, instead of 0.

	The trick of #defining dlopen and dlclose in order to catch
	calls to them simply doesn't work. A better method is being
	used now that actually catches all calls to dlopen/dlclose.
	This also allowed to reliably reset type_info pointers in the
	alloc_ct of allocations done from a loaded module that used
	AllocTag and is leaking that memory. Before, an application
	would core dump when dumping (apparently leaking) allocations
	done in a module that was dlclosed already and for which
	AllocTag was used, because the static type info object is
	part of the shared object which was unloaded, leading to
	reading invalid memory.

	As of g++-4.0.2 yet ANOTHER mt_alloc implementation was released
	with the gcc compiler. This time making it near impossible to
	use it. Getting really tired of this, libcwd now comes with it's
	own allocator, so that this upgrade problem has been solved once
	and for all. The new allocator is used with gcc-4.0.0 and higher.

libcwd-0.99.40

	Bug fixes:
	
	libcwd didn't compile with the g++ 4.0.0 that was actually
	released.

libcwd-0.99.39

	Updated support for g++ 4.0.0.

	The gdb functions debug_alloc and debug_watch have been
	renamed to cwdebug_alloc and cwdebug_watch respectively
	because they could no longer be static (gdb didn't see
	them anymore) and otherwise would polute namespace too
	much.

        Bug fixes:

	debug_ct::push_marker was broken. It left allocations
	at 'internal' causing fatal error messages in a subsequent
	delete or free about the attempt to delete a non-internal
	memory allocation with memory allocation checking off.

	The size of stripped shared libraries was incorrectly
	determined (the end of the library was set to the end
	of the first function in the library instead of the last).
	As a result, addresses in such libraries resulted in
	not being able to lookup the correct shared object file.
	Moreover, printing a location_ct with such an unknown
	object file would core dump.

	The creation of a std::ios_base::Init does still allocate
	memory with g++ 3.3 and higher if that compiler is
	configured with --enable-nls, as is the case for Gentoo.
	As a result, libcwd - that assumes no memory was allocated
	anymore as of 3.3 - would core dump even before reaching
	main.

libcwd-0.99.38

	Added support for g++ 3.4.2 and 4.0.0.

	Configuration with --disable-location has been fixed and
	is now supported.

	Cygwin and mingw32 are now supported when configuring with
	--disable-alloc and --disable-location (only debug output).
	Threading had not been tested on cygwin, and doesn't work
	on mingw32 (use --disable-threading).

        Bug fixes:

	On fedora core 2 it has happened that unnamed 'shared
	libraries' are being mapped and listed in the dl_loaded
	list.  This caused libcwd to crash with the error:
	FATAL  : std::ifstream.open(""): ENOENT (No such file or directory)

	A debug channel that was not included in the vector of
	debug channels (as is used for ForAllDebugChannels),
	like RCFILE, caused an ASCII 0 to be printed as part of its
	string when later another channel with a larger name was
	created.

	'type_info_of' could not be used safely from constructors
	of global objects.

	Configuration with --disable-alloc caused problems when
	using libcwd in a library.

libcwd-0.99.37

	Added support for g++ 3.4.1.

	The format of how a location_ct is written to an ostream
	can now be controlled with libcwd::location_format().
	It takes the same bit masks as the alloc filter, though
	restricted to the flags 'show_objectfile', 'show_function'
	and 'show_path'.  Instead of printing "<unknown function>"
	libcwd will now print the objectfile and the mangled
	function name of that location.

	The location at which memory is allocated is now also
	printed at the moment the memory is allocated and not only
	when it is being deleted. It is appended after the
	return value of the allocation function in square brackets.
	For example:
	MALLOC  : malloc(52) = 0x8076528 [ld-linux.so.2:_dl_map_object_deps]

	list_allocations_on now returns the number of printed
	allocations (unfiltered and not invisible). If that number
	is different from the real number of allocation, it will
	append a line like this one:
	MALLOC  : Number of visible memory blocks: 5\.
	Note that 'visible' there means that it was printed, not
	that they are not invisible (it is possible to have
	not-invisible memory blocks not being printed when they are
	being filtered by the ooam_filter_ct object that was passed).

	Added was a function ooam_filter_ct::hide_functions_matching
	that allows to hide allocations from the Overview Of Allocated
	Memory that were allocated from a certain function (and a
	certain shared library, if needed).

	A new flag alloc_filter_ct::show_function was added, causing
	list_allocations_on to print the mangled function name from
	which an allocation was done, even when the sourcefile and
	line number is known.

	Two new functions have been added to namespace libcwd:
	set_invisible_on() and set_invisible_off().  These should
	be called in pairs, just like turning off and on the
	debug channels.  Any memory that is allocated while
	invisibility is turned on will be invisible (hidden
	from the allocated memory overview and any leak detection
	you might have) automatically. Note that using this is
	merely a special case of using a memory marker with
	<code>invisible</code> set and using a filter that filters
	everything; you might still want to use a marker and
	use its filter for fine tuning, instead.

	libcwd::ooam_filter_ct does not allocate normal memory anymore
	(only `internal' memory) making it better suitable to use it
	as a filter to show memory leaks at program termination.

	Support for automake version 1.8 has been added.

	API changes:

	Two classes have been renamed:
	ooam_filter_ct --> alloc_filter_ct
	ooam_format_t  --> alloc_format_ct
	Where 'alloc' means 'memory allocation(s)'.
	The reason for the change is that the filter is being used
	in more and more places that are not directly related to the
	Overview Of Allocated Memory (ooam).

	location_ct::location_ct(void const*) has been made explicit.

libcwd-0.99.36

	Libcwd is now compiled with -O2 by default.
	Several files that shouldn't have been in the tar ball were
	removed from the release.
	The distclean target was fixed.

	API changes:

	The following methods have been removed from debug_ct:
	void set_margin(std::string const& s);
	void set_marker(std::string const& s);
	std::string get_margin(void) const;
	std::string get_marker(void) const;
	Instead use debug_ct::margin() and debug_ct::marker()
	and the methods of the class that is returned
	(ie libcwd::debug_string_ct::assign).
	See reference-manual/classlibcwd_1_1debug__ct.html

        Bug fixes:

	The example-project didn't compile because of the usage
	of #ifdef instead of #if in debug.cc.

libcwd-0.99.35

        Bug fixes:

	It was not possible to make realloc()-ated memory invisible.

	Changes:

	Memory that was invisible and is then realloc()-ated will
	now stay invisible.  Memory that is allocated that is
	invisible will have a "(invisible)" remark behind it.
	For example:
	MALLOC    : realloc(0x84ad7f8, 64) = 0x849e5f8 (invisible)

	API changes:

	A new setup for libraries that use libcwd has been designed.
	This new design allows third-party library headers to
	include <libcwd/libraries_debug.h> (not <libcwd/debug.h>!)
	The new design also requires library authors to define their
	own ForAllDebugChannels and ForAllDebugObjects macro for use
	in their headers files, if they need that.  Before, this was
	only needed for Dout, DoutFatal and Debug, but use of
	ForAllDebug* was theoretically broken in library headers under
	very specific circumstances [ involving two libraries that
	  both use libcwd and have a channel name collision which the
	  end-user resolves in favour of library1 while library2 uses
	  a ForAllDebug* macro in its headers and refers to the
	  colliding debug channel inside this ForAllDebug*; it then
	  would get the channel of the other library. ]
        Moreover, as a result of this design, one should use
	LIBCWD_DEBUGCHANNELS instead of DEBUGCHANNELS when using
	this macro.  You still *define* DEBUGCHANNELS, before including
	<libcwd/debug.h>.
	The means that the following changes need to be made.

	End-application authors:
	- Change all occurances of DEBUGCHANNELS, except the one where it
	  is defined (in your "debug.h"), into LIBCWD_DEBUGCHANNELS.

        Library authors:
	- Change all occurances of DEBUGCHANNELS in your source files
	  and local headers, except the one where it is defined (in your
	  local "debug.h"), into LIBCWD_DEBUGCHANNELS.
	- Make sure you are not using DEBUGCHANNELS in your headers, if
	  you do - change it to the literal namespace (for example
	  'libwhatever::channels') of your library.
        - Replace in your headers any occurance of 'ForAllDebug*(' with
	  'LibcwdForAllDebug*(libwhatever::channels, ', where 'ForAllDebug*'
	  is either ForAllDebugChannels or ForAllDebugObjects and
	  'libwhatever::channels' is the namespace in which your library
	  defines its 'dc' namespace with library specific debug channels,
	  or use your own macros for this (see url below).
	- In your headers, replace
	    #ifndef LIBWHATEVER_DEBUG_H
	    #error "You need to include the appropriate debug.h in the \
	            source file, before including this header file."
	    #endif
	  with
	    #include <libwhatever/debug.h>
	  And read carefully the page on
	  reference-manual/group__chapter__custom__debug__h.html#libraries
	  for further instruction on how to set up respective debug header
	  files.

libcwd-0.99.34

	Turning on of dc::malloc and dc::bfd in rcfile_ct::read is
	delayed till all of the rcfile is processed.  This prevents
	printing of MALLOC and BFD messages in the case that those
	channels are turned off at the start of processing the rcfile
	even if they are temporarily turned on.

	API changes:

	Namespace libcw::debug has been replaced with namespace libcwd.
	In most case you should be able to just replace all occurances
	of 'libcw::debug' with libcwd without problems.  If for some
	reason this change has a too dramatic effect on your application
	then you can also add this to your custom debug.h file:
	namespace libcw { namespace debug = ::libcwd; }
	directly after including libcwd/debug.h.

	Bug fixes:

        A Shared Object file with more than 256 .debug_abbrev entries
	caused undefined behaviour.  Thanks to Vladimir Prus for
	reporting this problem.

	The non-threaded library could core dump at exit due to a
	global object destruction order fiasco.  If libcw_do was
	destructed before rcfile (or any other global object doing
	memory allocations from its destructor) and dc::malloc is
	still turned on.

libcwd-0.99.33

	New function debug_watch(ptr).  You can call this from within
	gdb and it will cause a breakpoint when the memory pointer
	ptr that is passed to it is being freed.

	Added support for pkg-config(1).
	See http://www.freedesktop.org/software/pkgconfig
	This means you can use `pkg-config --cflags` and
	`pkg-config --libs` in your configure script in order
	to get the flags that libcwd needs.

	The allocator implementation has been adjusted in order
	to work again with the latest __pool_alloc of g++ 3.5 cvs.

	Bug fixes:

	The tar ball distribution was missing include/pch-source.h,
	making it fail to compile with g++ 3.4 or higher.

	Compilation failed when configured with --enable-maintainer-mode
	because example-project/debug.h.maintainer is not distributed.
	A workaround for this has been added.

libcwd-0.99.32

	Support for a runtime configuration file (.libcwdrc) has been
	added.  This file can be used to set the debug channels.

	A new function `attach_gdb()' was added.  When called, it
	opens a terminal window with a gdb session allowing one to
	debug the application from that point onwards.

	Documentation for both functions above has been added to the
	reference manual.

	The code was adjusted to support the latest CVS version of
	the gcc-3_4-branch (20040220).

	Code has been added to correct wrong debug info as outputted
	by the commonly used GNU assembler version 2.3.90 as result
	of a frequently occuring bug.  Before this correction is was
	possible that libcwd was unable to determine the line number
	information of about 1% of the functions.

	The library now prints "Loading debug symbols from..."
	(if the environment variable LIBCWD_PRINT_LOADING is set)
	and "Loading debug info from..." seperately.

	A function was added that is intended to be called from gdb like:
	(gdb) call debug_alloc(0x84002f2)
	It prints information about the pointer passed to it.  This
	function can ONLY be called from within gdb, to assist in
	debugging memory allocation related problems.

	More bugs in the demangler have been fixed - however, if you
	write code that actually needs the cases that have been fixed
	then you should go and see a doctor.

        Work In Progress:
	
	The following is partically finished but not yet usable.
	It won't be in the way of normal usage though.
	- functions / stack stuff
	- New test environment (cutee)

	API changes:

	The debug channel constructor was changed from
	channel_ct::channel_ct(char const* label) to
	channel_ct::channel_ct(char const* label, bool add_to_channel_list = true).
        When add_to_channel_list is false, the channel will not be added
	to the list of channels as accessible with ForAllDebugChannels().

	Bug fixes:

	It happened that the location of an allocation done before
	libcwd is initialized would never get resolved, resulting
	in weird output like:
	MALLOC  : malloc(352) = 0x805a4c8
	MALLOC  : free(0x805a4c8) <pre libcwd initialization> <unknown type>; (sz = 352)
	Where the allocation of that specific instance clearly isn't
	"pre libcwd initialization".  The reason for this is that
	locations are cached: the delayed lookup was never performed.

	When libcwd could not determine the start of shared library
	it would core dump with the message  COREDUMP: bfd.cc:513:
	void libcw::debug::cwbfd::bfile_ct::initialize(const char*, void*):
	Assertion `!__libcwd_tsd.internal' failed.
	This was because 'internal' was still set, while since 0.99.29
	allocations inside Dout are treated as normal (non-internal).

	Several potential deadlocks have been fixed (potential means
	that I ran into a rare circumstance in which two locks were
	called in the reverse order than is usual - it is a thousand times
	less likely however that that happens at the same time another
	thread is locking them too, in the right order, causing the
	actual dead lock).  All of these potential deadlocks were related
	to initialization (and only would happen immedeately after
	starting the application) and ranged from 'probably nobody ran
	into this yet' to 'only when there really exist an infinite
	number of parallel universes there is a slight chance that
	this might actually happen - not in THIS universe however.'

libcwd-0.99.31

	Support for the Native POSIX Threads Library (NPTL)
	was added.  0.99.30 did work with glibc-2.3.2 but
	only with LD_ASSUME_KERNEL set to "2.2.5" (no NPTL).
	The development kernel 2.5 and the kernel that is
	distributed with RedHat 9 do support NPTL and therefore
	need this version.

	API changes:

	The method debug_ct::keep_tsd was removed.
	This function is no longer needed.  See README.threads
	for a description of how Thread Specific Data of
	terminating threads now is handled.

	Bug fixes:

        debug_tsd_st::finish accessed a bit in a memory block
	that was just freed.  As a result the 'flush_cf'
	control flag could be propagated wrongly from an
	'interupted' debug output to the output that it
	interupted.

	TLS symbols in a TLS enabled library (i.e. glibc-2.3.2 
	of RedHat 9) did confuse libcwd and could lead to a
	wrong function name being resolved for a given address.

libcwd-0.99.30

	Libcwd now works with glibc-2.3.2 (RedHat 9).

	Bug fixes:

	Several minor thread related bug fixes.

	Threaded applications could errornously filter away
	allocation in an allocated memory overview because
	allocation made after between two calls to
	list_allocations_on using the same filter would
	be filtered on an uninitialized boolean.

libcwd-0.99.29

        Allocations inside Dout() et al are not 'internal' anymore.
	Although it makes no sense to explicitly allocate memory in
	debug code, there were problems with implicitly allocated
	memory as part of libstdc++ (like a locale object and a
	scratch buffer for writing numbers), these allocation should
	be non-internal - and when occuring from within a Dout did
	sometimes lead to a COREDUMP, complaining about freeing
	'internal' memory.

	Support for 2.95.x and 2.96 (RedHat 7) has been dropped.
	Minimum compiler requirement is now 3.0, 3.2.x is recommended.
	This was necessary because these older versions don't
	fully support string buffers with allocator support, they
	are not standard compliant.

	Libcwd now compiles and works with the (current) CVS branches
	of g++ 3.3 and 3.4.

	API changes:

	The directory include/libcw was renamed to include/libcwd.
	The headerfile sysd.h was renamed to sys.h.
	The headerfile debug_config.h was renamed to config.h.
	This means that you will have to update your debug.h and
	sys.h files for the applications that use libcwd:
	#include <libcw/sysd.h>     --> #include <libcwd/sys.h>
	#include <libcw/debug.h>    --> #include <libcwd/debug.h>
	And, in case you use these:
	#include <libcw/cwprint.h>  --> #include <libcwd/cwprint.h>
	#include <libcw/buf2str.h>  --> #include <libcwd/buf2str.h>
	#include <libcw/char2str.h> --> #include <libcwd/char2str.h>

	Bug fixes:

	It could happen, while writing debug output, that you'd see
	something like:
	  COREDUMP:     internal free: You are 'free()'-ing a pointer with alloc 
	  checking OFF ('internal' allocation) (0x807e570) that was allocated with 
	  'malloc()'.  Use 'free' instead.
	  Aborted (core dumped)
	While in fact you didn't free anything at all (the free is
	done internally by libstdc++ and out of your control).
	This should be fixed now.

	When one thread is listing memory allocations and another
	thread is closing a shared library, it could happen that
	a type_info reference in the listing did not exist anymore
	by the time it was listed, resulting in a crash.
	This was fixed with a mutex that excludes calls to dlclose
	and listing memory allocation for all threads.  Note that
	this can still happen when a shared library is closed that
	leaked memory.

	Two threads reaching the same AllocTag at the same time,
	and for the first time that it is reached (very unlikely
	thus) caused a race condition on the static description
	pointer.  A critical area for the (one time) initialization
	of the description has been added.

libcwd-0.99.28

	Bug fixes:

	Configuration with --disable-alloc was still broken on SunOS.

	The mangling was changed in g++ version 3.1 (rendering C++ libraries
	compiled with previous versions binary incompatible).  The demangler
	of libcwd was updated to reflect this change.  As a result, libcwd
	will not always correctly demangle applications that were compiled
	with g++ versions 3.0.x anymore.

	Under certain circumstances, the decoding of the line numbers
	of DWARF2 .debug_line section failed.  In particular, the
	last source line of functions was failing often.  Most notably
	that was confusing when the last line of an inlined function
	needed to be located.  The lookup now has been extensively tested
	(to correctly lookup every possible location in a -O2 compiled
	libstdc++-5.0.2).

	Only half of the new/delete signatures in <new> were supported.
	As a result, applications that used new(std::nothrow_t) would
	abort with the error: "COREDUMP: You are `delete'-ing a block that
	was allocated with `malloc()'!  Use `free()' instead."
	In particular gtkmm-2.0 and higher is using such a call.
	(Bug reported by Marek Materzok).
	The following signatures have been added to libcwd now:
	void* operator new(std::size_t, std::nothrow_t const&) throw();
	void* operator new[](std::size_t, std::nothrow_t const&) throw();
	void operator delete(void*, std::nothrow_t const&) throw();
	void operator delete[](void*, std::nothrow_t const&) throw();

	There is a bug in the g++ compiler that is not likely to be
	fixed very soon; see http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=38
	Therefore, a workaround for this bug was added in order to
	make cwprint_using work when the print method is a method of
	the base class.  The latter now takes two template parameters:
	template<T, T_OR_BASE_OF_T>
	  cwprint_using_tct<T_OR_BASE_OF_T>
	  cwprint_using(T const&, void (T_OR_BASE_OF_T::*)(std::ostream&) const);

	dlopen() failed when a relative path was given. It now
	also works when the filename is somewhere in LD_LIBRARY_PATH,
	or /etc/ld.so.cache, etc., but only when glibc is used (more
	precisely, libcwd assumes that the handle that is returned by
	dlopen() is actually a link_map pointer).

	If an object file has both stabs and DWARF2 debugging information
	then the stabs information was ignored.  This turns out not to be
	correct because it is possible that there is line number information
	in the .stabs section that is not in the .debug_line section when
	the latter is part of the usual crt*.o object files of g++-2.95.x
	in the case that this compiler was compiled with -gdwarf-2 or with
	gcc-3.x.  Libcwd now reads and combines the debugging info from
	both kinds.

libcwd-0.99.27

	Bug fixes:

	Libcwd would core dump when reading the DWARF debug info from
	a library whose last compilation unit did not contain a
	.debug_line section.

	Configuration with --disable-alloc was broken.

	The demangler for the new ABI didn't demangle global
	constructors/destructors keyed to functions (mangled names
	starting with _GLOBAL__[ID]_, a GNU extension).

libcwd-0.99.26

	Changes:

	It is now possible to hide allocations from the Overview Of
	Allocated Memory whose allocation location could not be determined.
	Those allocations would always show up, using the function name
	of the function where the allocation was done.
	[ ooam_filter_ct::hide_unknown_locations(bool) ].

	Support for glibc-2.2.5 has been added.  This means that the
	testsuite should not report errors anymore and that _dl_loaded
	is detected and used again (as member of _rtdl_global).

	Bug fixes:

	Several README files that should have been part of the distribution
	were not!  Added: README.CVS (explains how to download libcwd
	from cvs), README.solaris (explains that threading doesn't work
	on solaris), README.threads (general information on how to debug
	threaded applications).

	The demangler was decoding 's' into "internal_string" instead of
	"std::string".  A left-over from an old find & replace.

	There was still a problem with third party C++ libraries whose
	first allocation - as part of the initialization of that library -
	is from std::allocator.  The initialization of libcwd now also
	uses a private memory pool for 'userspace' allocations.

libcwd-0.99.25

	Changes:

	channel_ct::get_label() was returning a character array of size
	max_label_len_c, right padded with spaces and not zero terminated.
	Now it returns a zero terminated character array.  The length
	of the string is equal to the length of longest label (so dlopen-
	ing a library with a longer debug channel will actually increase
	the size of all other labels).

        Bug fixes:

	The previous version erroneously did not compile with -O.

	When using g++ version 2.95.x or 2.96 then multi-threaded
	applications could core dump because demangle_symbol and
	demangle_type were not thread safe.

	list_allocations_on only worked for libcw_do, not for a
	custom debug object.

	Memory leaks that were introduced in 0.99.20 have been fixed
	for AllocTag (leaked 20 bytes, now does not allocate anything
	at all to begin with) and list_allocations_on (the copy of the
	memory allocation administration was never freed, ugh).

	location_ct was leaking memory (the filename was never deleted).

	When using a third party library (like libMagick++), it is
	possible that the first allocation - as part of the initialization
	of that library - is from std::allocator.  The vector that is
	being using to store all debug objects was erroneously using
	std::allocator as well, causing a dead lock during the initialization
	of libcwd for threaded applications in such a case.

libcwd-0.99.24

        Bug fixes:

	https://sourceforge.net/tracker/?func=detail&atid=449767&aid=573370&group_id=47536
	has been fixed.  When gcc is configured with --enable-sjlj-exceptions
	then every call to C++ functions is accompanied by a call to
	_Unwind_SjLj_Register that calls __pthread_setspecific that
	calls calloc.  We can't have that for two reasons: Firstly,
	it causes easily an infinite recursion when a C++ function is
	called from calloc (which is what we obviously do) and
	secondly, when libcwd is doing internal allocations it also
	calls (C++) functions which then would cause the allocations
	done by __pthread_setspecific to be 'internal' and that causes
	problems as well.  The solution was to compile libcwd with
	-fno-exceptions.  Of course you can still use exceptions in
	the applications that link with libcwd.

	The configure options --disable-alloc and --disable-location
	now work again.

	When allocating 0xffffffff bytes, libcwd would - instead
	of reporting an Out Of Memory - allocate 11 bytes and CORE when
	you tried to free that memory again.  The reason is that it
	adds 12 to the size for the magic numbers.  Now it will detect
	large sizes and generate an Out Of Memory.

	A possible core dump with a backtrace like:
	#0  0x403cb4f1 in strlen () at strlen:-1
	#1  0x400abbe9 in operator<< (os=@0x85a3748, data=0xbf7ff9dc "\002\001") at include/cwd_debug.h:55
	#2  0x4008295f in libcw::debug::dm_alloc_base_ct::print_description(libcw::debug::ooam_filter_ct const&,
	                  libcw::debug::_private_::TSD_st&) const (this=0x85a3748, filter=@0xbf7ff9dc,
			  __libcwd_tsd=@0x807ccc8) at debugmalloc.cc:1250
        where 'a_type' (see debugmalloc.cc in frame #2) is NULL was fixed.
	This could occur in multi-threaded applications when one thread
	is using list_allocations_on() while another thread is demangling
	a C++ type with demangle_type() or demangle_symbol().

	Continued debug output now also works with multi-threading,
	printing <unfinished> and <continued> as expected when a
	different thread is writing output in the meantime.
	The use of nonewline_cf in combination with other threads
	will result in "<no newline>\n" being appended to unfinised
	output, for example:
	Thread1 NOTICE abcd<no newline>
	Thread2 NOTICE interrupt
	efgh
	Note that in this case the prefix is not repeated. The use
	of nonewline_cf in a multi-threaded application is therefore
	dissuaded; use continued_cf instead to get for example:
	Thread1 NOTICE abcd <unfinished>
	Thread2 NOTICE interrupt
	Thread1 NOTICE <continued> efgh

libcwd-0.99.23

	The "Overview Of Allocated Memory" filter (ooam_filter_ct)
	has been extended with the ability to discriminate on the
	source filename of the allocation location
	[ ooam_filter_ct::hide_sourcefiles_matching(std::vector<std::string> const&); ].
	
	It is now also possible to only show allocations for which
	explicitly an allocation annotation (AllocTag et al) has
	been used [ ooam_filter_ct::hide_untagged_allocations(bool) ].

	An allocation marker (marker_ct) now accepts a filter (ooam_filter_ct)
	as second argument which is subsequently used to move 'hidden' allocations
	outside of the marker before testing for leaks.  Possible leaks are
	then listed using the show_* flags of the filter.

        Bug fixes:

	dlopen() can now be called multiple times for the same module;
	the related symbol table will not be deleted until dlclose()
	has been called as often as dlopen() was called.

	An allocation done in an object file  that was opened with dlopen()
	would cause a core dump in list_allocations_on when using a filter
	with show_objectfile when in the meantime dlclose() was called
	for that object file.

	The first part of the full path of a source file location was
	missing when using gcc 3.x.

libcwd-0.99.22

        Bug fixes:

	Using error_cf while interrupting continued_cf debug
	output could cause errno to be set to EINTR before
	printing the error message, in threaded applications.

	DoutFatal in thread applications could cause a deadlock
	because cancelling the main thread and then calling
	exit() causes the main thread to call waitpid()
	for the thread manager (which is already dead at that
	moment) which is a cancellation point and therefore
	tries to handle the cancellation of the main thread,
	which hangs because the thread manager is already
	gone (a bug in libpthread imho).

	Doing a realloc for an allocation without description
	caused a core dump.  That made libcwd fail with most
	third party libraries I'd think (libstdc++ doesn't
	seem to use realloc).  Once again I am AMAZED that
	nobody reported this horrible bug and I had to run
	into it myself (bug was introduced in 0.99.20).

libcwd-0.99.21

	The library now compiles with g++ version 3.1 and
	was fixed to understand the changes in the DWARF2
	format of gcc 3.1.

	README.threads has been updated with important
	information.

	make_all_allocations_invisible_except() now only makes
	allocations invisible that were allocated by the
	current thread.

	The administration of allocated memory is now kept
	in an STL map *per* thread instead of one big global
	map.  The advantage of that is that in general a
	call to new/malloc etc. will not cause a thread to
	have to wait for other threads anymore.

	API changes:

	location_ct::location_reference() has been removed.
	This member function was only there because previously
	we needed a delayed initialization of the location_ct
	that is part of class alloc_ct, but since 0.99.19 we
	use location caching and now the location in alloc_ct
	was replaced with a pointer into this cache.
	The write access (via location_reference) now had to
	be removed because it is not thread-safe to allow the
	user to write to the cached location objects.

	Bug fixes:

	Location lookups done before libcwd is initialized are
	delayed until the first time list_alloctions_on is
	called.  This was broken in 0.99.20 but has been fixed
	again now.

	Version 0.99.19/20 did not compile on Suse (7.1) because
	of a missing #include <sys/time.h>.

	list_alloctions_on could cause a stack overflow due to
	recursive deep copying of the allocation linked list;
	now using an iterative copy.

	As a result of seperating the allocation administration,
	memory allocation markers now function again as they will
	only report memory leaks when the *current* thread has
	allocated memory.

	Fixed a potential deadlock related to the use of dlopen().
	Code was added to detect potential deadlocks without that
	they actual happen.  The only potential dead locks that
	should be left are ones related to exceptions like a
	DoutFatal or thread cancellation.

libcwd-0.99.20

	Several small adjustments have been made to support the
	native linker of solaris 2.8.  As a result, libcwd is
	now usable on solaris 2.8, although not 100% bug free.
	Threading still only works on linux (there is a good
	reason for that, related to the fact that libcwd needs
	to keep working even after a thread is de-initialized
	and the fact that linux threads is abusing a mutex in
	a way that causes a unavoidable deadlock when we use
	semaphores in malloc et al; to make a long story short,
	libcwd can't use the POSIX threads 'Thread Specific Data'
	support for its thread specific data and we need to do
	some very unportable things in order to get everything
	working.  Well, you don't want to know about this, just
	believe me that it is NOT simple to add support for
	other OS).

	Bug fixes:

	The internal function ST_get_full_path_to_executable was
	using ST_internal_string without setting allocation off.
	I don't think that could have bad effects during normal use,
	but it did lead to a coredump with allocation debugging
	(of libcwd itself) on.

	gcc version 2.9x was using strstream as internal_stringstream,
	and although only used with alloc checking off this DID lead,
	under special circumstances, to a deadlock in list_allocations_on.

	When an error occured during a call to dlopen (a macro to
	__libcwd_dlopen) the call to dlerror would cause a deadlock
	because it calls malloc which causes a location lookup
	which uses the same mutex as is already set in __libcwd_dlopen.
	This lock is now released prior to calling dlerror.

	Commented out the call to pthread_kill_other_threads_np prior
	to raising SIGABRT because it is buggy (it only makes my
	application hang here).  Hopefully this won't cause a core
	dump for the wrong thread too often :/

        When using error_cf, the call to strerror was done with
	alloc checking off, but it calls malloc and is a library
	(libc) function, so that allocation should be done in
	'user space'; not doing so would cause an error when the
	next call to strerror is done by the user.  More over,
	strerror is not reentrant.

	The call to dm_alloc_ct::print_description in internal_free
	that prints the description of the allocation that is being
	freed was errornously passed a '0' instead of the constant
	default_ooam_filter; that in turn caused the synchronization id
	of the filter object to be increased every time, which caused
	a deadlock if the mutex used for the filter id was already set
	(something that could easily happen because free is called in
	the critical area of that mutex).

	list_allocations_on could also easily cause a deadlock
	because it was printing the allocation list directly from
	the map<> that is being used to administrate the allocations
	and thus kept a lock for allocations during printing.
	Because obviously we can't print to stdout or a file etc
	without using user-space allocations, the only solution is
	to first make a copy of the information that needs to be
	printed before actually printing it.  In the next version
	I will use a seperate administration per thread so that
	memory that is allocated and freed by the same thread
	won't block other threads (much like glibcs malloc) and
	that in turn will make it possible to make an important
	improvement here that also will make markers thread-safe.

libcwd-0.99.19

	The package now builds two libraries by default: libcwd.so
	and libcwd_r.so.  The latter is thread-safe.  Both use the
	same headerfiles that assume thread safety when either one
	of the macros _REENTRANT or _THREAD_SAFE are defined.

	FreeBSD, that does not have __libc_malloc but does have
	dlopen(), now also uses malloc with external C linkage:
	malloc et al are looked up with dlsym() (instead of defining
	malloc et al as a macro).  This means that also on FreeBSD
	ALL allocations are accounted, including those done by third
	party libraries.

	Source file / line number lookups for memory allocations are
	cached, which is slightly faster but mostly made it possible
	to use pointers to the file names instead of duplicating
	them, saving lots of memory when an application makes many
	allocations.

	It is now possible to show the time at which allocations are
	made in the Overview Of Allocated Memory and/or to show only
	allocations made in a given time interval.
	It is also possible to show the file name of the shared library
	or executable that the location at which the allocation was
	made belongs to and/or to selectively filter away allocations
	belonging to specified shared libraries.

	Bug fixes:

	The demangler for the old ABI (g++ versions <= 2.96)
	still contained a (non-internal) std::vector causing a
	deadlock while demangling the functionname in which another
	STL allocation is done (which uses a single mutex).
	[ Thus: STL container allocation --> sets lock --> calls
	  malloc --> looks up location --> demangles function name
	  --> uses STL vector --> tries another allocation -->
	  deadlock ].  This problem did not occur for g++ 3.x
	because then we _already_ used _private_::internal_vector,
	as should be.

libcwd-0.99.18

	API changes:

	All macros related to the configure options used have been
	renamed and are no longer either defined or undefined, but
	rather defined to 1 or 0 respectively.  The advantage of
	that is that it allows the compiler to warn you when you
	made a typo in a macro name.
	This means that you will have to use #if macro_name
	instead of #ifdef macro_name of course.
	The names have changed as follows:
	Locations:
	DEBUGUSEBFD		-->	CWDEBUG_LOCATION
	Memory allocation debugging:
	DEBUGMALLOC		-->	CWDEBUG_ALLOC
	DEBUGMAGICMALLOC	-->	CWDEBUG_MAGIC
	DEBUGMARKER		-->	CWDEBUG_MARKER
	Debugging libcwd itself:
	DEBUGDEBUG		-->	CWDEBUG_DEBUG
	DEBUGDEBUGOUTPUT	-->	CWDEBUG_DEBUGOUTPUT
	DEBUGDEBUGMALLOC	-->	CWDEBUG_DEBUGM
	DEBUGDEBUGTHREADS	-->	CWDEBUG_DEBUGT
	The rationale is that for a configure option
	--enable-xxx, the macro name is now CWDEBUG_XXX.
	The configure options are also renamed: the 'libcwd-'
	part is removed (--enable-libcwd-xxx --> --enable-xxx).
	You are advised to automate the replacements of the
	macros (use find and grep and reg.exp replaces);
	The following substitutions are suggested (only
	given for one of the macros):
	:%s/defined(DEBUGDEBUG)/CWDEBUG_DEBUG/g
	:%s/#ifdef DEBUGDEBUG /#if CWDEBUG_DEBUG /
	:%s/#ifdef DEBUGDEBUG$/#if CWDEBUG_DEBUG/
	:%s/#ifndef DEBUGDEBUG /#if !CWDEBUG_DEBUG /
	:%s/#ifndef DEBUGDEBUG$/#if !CWDEBUG_DEBUG /
	:%s%// DEBUGDEBUG$%// CWDEBUG_DEBUG%
	:%s%// !DEBUGDEBUG$%// !CWDEBUG_DEBUG%
	After that you still have to check if other instances
	are left.

	MACRO OVERVIEW:
	Most macros now either start with LIBCWD_, LIBCW_, CWDEBUG_
	or Libcw.  The macros that start with LIBCW should not
	be used.  The macros that start with CWDEBUG_ are either
	0 or 1 and should be used as #if CWDEBUG_XXX ...
	CWDEBUG itself is still defined or undefined and should
	be used as #ifdef CWDEBUG ...
	The macros that start with Libcw are the more general
	cases of Dout, DoutFatal and Debug (they are LibcwDebug,
	LibcwDebugThreads, LibcwDout, LibcwDoutFatal, LibcwDoutFatalScopeBegin,
	LibcwDoutFatalScopeEnd, LibcwDoutFatalStream, LibcwDoutScopeBegin,
	LibcwDoutScopeEnd and LibcwDoutStream).  You are allowed to
	use those to customize things.
	The macros that do not start with one of those four prefixes
	are part of the libcwd API (and should also be defined in
	your custom debug.h):
	  Debug, Dout, DoutFatal
			: see documentation/reference-manual/debug_8h.html
	  DEBUGCHANNELS	: see documentation/reference-manual/group__chapter__custom__debug__h.html
	  ForAllDebugChannels and ForAllDebugObjects
			: see documentation/reference-manual/group__group__special.html
	  AllocTag, AllocTag1, AllocTag2, AllocTag_dynamic_description and NEW
			: see documentation/reference-manual/group__group__annotation.html
	When you don't have __libc_malloc/_libc_malloc (glibc *does* have that):
	  malloc, calloc, realloc, free, strdup, wcsdup and RegisterExternalAlloc.
	These are always defined because there is no accessible __libc_dlopen:
	  dlclose, dlopen : In order to catch those when used.

libcwd-0.99.17

	A tutorial on debugging threaded applications was added.

	Bug fixes:

	The specialization of template
	_private_::lock_interface_tct<pthread_mutex_t*>
	was accidently left out of its header file, resulting in
	the compile error:
	/usr/include/libcw/private_lock_interface.h:38: no matching
	  function for call to `pthread_mutex_t::trylock()'
        when trying to pass a pthread_mutex_t to debug_ct::set_ostream.

	Libcwd failed to find an executable in the current directory
	when one of the command line parameters contained a '/'.

	The tutorial had several occurances of '<' where '&lt;' should
	have been used, with as result that parts of example code didn't
	show up in a browser.

	`pthread_kill_other_threads_np' was not detected by ./configure.

	Due to a problem with how RedHat ships fonts, using mozilla,
	italic helvetica looks horrible.  The documentation now uses
	plain 'sans-serif' instead which will use the default font
	that is defined under preferences -> appearance -> fonts.
	This should be set to -adobe-helvetica-*-.

	list_channels_on didn't print the margin.

	Fixed a deadlock in object_file_ct::find_nearest_line().
	The deadlock occured when debug output written from
	load_dwarf/load_stabs, which must be done with userspace
	allocations, caused a recursive entry into this function.

	Fixed a deadlock in std::__default_allocator<true, 0>, the
	default userspace allocator of the STL.  The problem here
	is that this lock is set when it calls malloc() to increase
	its internal memory pool, causing a deadlock when memory
	needs to be allocated during the writing of debug output
	to dc::malloc or dc::bfd (this happens *extremely* seldom,
	I even knew about this when I released 0.99.16).  The solution
	is to queue messages instead of writing them to the final
	ostream when we find that the std::__default_allocator<true, 0>
	is set and we are printing debug output from within malloc()
	et al (then we assume we took the lock).  The queued messages
	are flushed the first time this condition is not true.  The
	queue is debug object specific which means that if you use
	two or more different debug objects that write to the same
	ostream, the ordering of messages could become non chronologic,
	but then again - we could also put a man on Pluto next year.

libcwd-0.99.16

	* libcwd is now thread-safe *
	You have to configure using --enable-libcwd-threading.

	The source file line number lookup was improved for optimized code with
	inlined functions (-O).

	New configuration option --disable-libcwd-debug-output was added to
	allow the use of the testsuite together with --enable-libcwd-debug.
	(You shouldn't use either unless you are hacking libcwd itself).

        New are environment variables that influence libcwd.
	At the moment there are two:
	LIBCWD_NO_STARTUP_MSGS : Don't print anything before main().
	LIBCWD_PRINT_LOADING : Print messages about loading
	the shared libraries, even when this is done before libcw_do
	is turned on (except when LIBCWD_NO_STARTUP_MSGS is defined).

	Miscellaneous:
	- The configuration option --disable-libcwd-location is fixed.
	- Automake-1.5 now works.
	- Autoconf-2.5x now works.
	- FreeBSD works (again).

	API changes:

	IMPORTANT: 'channel_ct const' -> 'channel_ct'.
	Debug channels should no longer be declared constant.
	[ "libcw::debug::channel_ct const my_channel("FOO");" -->
	  "libcw::debug::selector_ct my_channel("FOO");" ]

	`long memblks()' has been renamed to `unsigned long mem_blocks()'.
	[ "memblks()" --> "mem_blocks()" ]

	The margin and marker are no longer using std::string, which is
	a bit slow.  Access to the margin and marker is now granted through
	debug_ct::margin() and debug_ct::marker().  The returned objects
	provide the following methods: size(), c_str() (this just returns
	an internal pointer, the termination zero is already there),
	reserve(), capacity(), append(), prepend() and assign() - all with
	their meanings borrowed from std::string.  For example, when
	capacity() returns a value larger or equal to the length of a string
	that would result from a call to append(), then calling append is
	garanteed not to invalidate the pointer returned by c_str().  The
	default capacity can be set with `reserve'.  append/prepend/assign
	accept both a std::string reference or a char*/size_t pair.
	Finally, the following methods are added to debug_ct:
	`push_margin()', `pop_margin()', `push_marker()' and `pop_marker()'.
	These functions can be used to quickly store and restore the
	respective formatting strings.
	[ "Debug( libcw_do.set_margin(std::string(buf, len)) );" -->
	  "Debug( libcw_do.margin().assign(buf, len) );" ]


	A debug function for internal use (by the maintainers):
	`debugdebugcheckpoint()' has been removed.  If you need a user
	function to be called every Dout() then define your own Dout
	macro's, that makes more sense then recompiling libcwd.

	CWASSERT was renamed to LIBCWD_ASSERT; Note that all macros that start
	with LIBCWD_ should NOT be used by the user, they are for internal use
	by libcwd.
	[ "CWASSERT( i == 1 );" --> "assert( i == 1);" ]

	debug_ct::get_os() has been removed.  Use cwprint or cwprint_using.
	Reason: the temporary stringstream that was returned was only valid
	inside a Dout to begin with.  The use of get_os() was dangerous.

	You will need to add
	#ifndef _GNU_SOURCE
        #define _GNU_SOURCE
        #endif
	to your "sys.h" file, prior to including any other header file,
	just before including <libcw/sysd.h>.  This is needed because libcwd
	uses GNU extensions.  Of course, it is not necessary to define
	_GNU_SOURCE when CWDEBUG isn't defined, so you may put it inside the
        #ifdef CWDEBUG ... #endif.
	If you don't understand this, read documentation/reference-manual/preparation.html.

	Bug fixes:

	When using .stabs, each first line of code after a source file scope change
	as a result of an inlined function resulted in a location lookup failure
	("No line number").

	The default std::allocator implementation uses static pointers to keep
	a private free list, allocating memory with malloc() in large chunks.
	The sharing of this memory pool with all STL containers, including
	std::string and std::stringstreams - and even the buffers of std::cout
	and std::cerr - caused `internal' allocations being mixed with `userspace'
	allocations and thus an incorrect error detection.
	Libcwd now uses its own allocators, with their own memory pool, for
	variables that need internal allocations.

libcwd-0.99.15

	libcwd now works with (single threaded) qt applications.  A few major
	bugs have been fixed.

	API changes:

	You now MUST use CWDEBUG, defining DEBUG will no longer work; it was
	incompatible with qt-2.2.4.

	The macro ASSERT, which is equivalent with assert when CWDEBUG is
	defined and empty when not, was renamed to CWASSERT.  The main reason
	for this is that qt already defines a macro called ASSERT.

	Bug fixes:

	A bug in the demangler for gcc-2.96 and earlier caused core dumps for
	symbols that started with _X... Since those are used a lot in X libs,
	libcwd was unusable with X windowing system applications (like those
	using qt).

	Wrong demangling or a core dump could occur during the demangling of
	symbols used in type_info_of<> when using g++ version 3.x.

	An abort on an 'assert(func_addr)' could happen for .stabs N_FUN entries.
	The latest glibc caused this - making libcwd unusable.

	Due to a bug in the installation of g++-3.0.x, the use of -I- caused
	the header file gthr-default.h not to be found and as such failure of
	compilation of libcwd with an out-of-the-box installation of gcc.

libcwd-0.99.14

	Bug fixes:

	On systems where a 'char' is unsigned, the line number lookup of DWARF
	failed.

	Systems with old binutils produce incorrect .stabs entries, causing
	the line number lookup of stabs to fail.  Libcwd now detects this and
	then aborts.

libcwd-0.99.13

	Support for dlopen() was added.  Because there seems to be no hook for
	dlopen, it's being defined as a macro (#define dlopen __libcwd_dlopen).
	However, if a dlopen isn't catched (for instance, because it is called
	from another library that is not using libcwd) and when <link.h> is
	available (as is on all OS that use glibc) then libcwd will
	automatically post-load any shared libraries as soon as it can not find
	the address of a location_ct.  Actually, the correct usage of the macro
	is only important in order to assure the correct unloading of symbols
	when a loaded module is dlclose-ed again (which is also defined as a
	macro).

	Improvement of the determination of the start of an object file.
	Unknown starts are now also correctly determined for very small shared
	objects.

	Support for the DWARF 2.0 debugging format has been added.

	Bug fix: previously local symbols were all thrown away, including
	static functions.  Now a source file / line number lookup inside a
	static function will work too.

	API changes:

	IMPORTANT: sys.h -> sysd.h.
	The header file sys.h has been renamed to sysd.h and was majorly
	cleaned up.  All macros that are not used in header files of libcwd
	have been removed.  Removed are: __restrict, NEED_SYS_TYPES,
	NEED_WORD_ALIGNMENT, NBLOCK_*, HAVE_RECURSIVE_BUILTIN_RETURN_ADDRESS,
	HAVE_FRAME_ADDRESS_OFFSET, CW_FRAME_ADDRESS_OFFSET, NO_ATTRIBUTE,
	NEED_FAKE_RETURN, UNUSED, USE, and __GXX_ABI_VERSION.  No header file
	is included anymore (it was possible that <sys/types.h>, <_G_config.h>
	and/or <streambuf.h> were included) and no typedefs are included
	anymore (removed: socklen_t, optval_t, retsig_t, sighandler_param_t
	and getgroups_t).  The constant malloc_overhead_c has also been
	removed from sys.h.
	YOU SHOULD HAVE been using #include "sys.h", containing:
	  #ifdef CWDEBUG
	  #include <libcw/sys.h>
	  #endif
	in effect causing the need to edit only one file (your "sys.h") and
	change <libcw/sys.h> into <libcw/sysd.h>.

	Debug channel WARNING is now on by default.  This means that you can't
	turn it on at the start of main: remove lines with
	Debug( dc::warning.on() ).

libcwd-0.99.12

	Bug fix release.

libcwd-0.99.11

	I changed my mind and renamed 'dc::stabs' back to 'dc::bfd'.  The label
	also is again "BFD".

libcwd-0.99.10

	MAJOR CHANGE: malloc, calloc, realloc and free are no longer macros but
	are now declared as external "C" functions.  This means that *all*
	allocations done by an application are now being caught, including
	those done from libc, libstdc++ and any other library that might be
	linked.

	IMPORTANT: The way nodebug.h was generated in the example-project was
	wrong.  If you used the example-project for your own project, then
	please look at the changes in maintMakefile.in and macrotest.cc.
	Alternatively you can use the nodebug.h file that is part of this
	distribution.

	Libcwd does not use libbfd anymore (and thus also not libiberty).  The
	symbol table is now read by libcwd itself as is the source file and
	line number lookup.  The configure option --disable-libcwd-bfd was
	therefore renamed to --disable-libcwd-location.  Added was the
	configure option --enable-libcwd-bfd in order to allow you to still
	use libbfd.

	The management of CWDEBUG has been made a bit clearer:  is not possible
	anymore to #include <libcw/debug.h> without defining CWDEBUG.  This to
	avoid confusion.

	For gurus only: Note that now it *is* possible to include
	<libcw/debugmalloc.h> directly, but only when CWDEBUG is *not* defined.
	In that case you will need to include a special "nodebug.h" that leaves
	the memory allocation support intact.  For this stripped down
	functionality of libcwd a bug was fixed: set_alloc_checking_off() and
	set_alloc_checking_on() are now still functional in that case.  In case
	non-gurus are reading this: Those two functions are not documented on
	purpose, just forget you ever saw this paragraph.

	API changes:

	::libcw_bfd_builtin_return_address_offset was renamed to
	libcw::debug::builtin_return_address_offset.

	The debug channel dc::bfd was renamed to dc::stabs and uses "STABS"
	as label now.

	Two methods have been added to class libcw::debug::debug_ct:
	`inc_indent' and `dec_indent' to increment and decrement the
	indentation respectively.

	The following only applies when __libc_malloc could not be found.
	Instead of using this you should really upgrade your libc.  If you use
	linux this most likely is not of concern to you.

	[ strdup(3) and wcsdup(3) are now treated like malloc(3), which means
	  that they are macros.  The default AllocTag used is "strdup()" and
	  "wcsdup()" respectively, but one can easily override that.  For
	  example:
	    char* s = strdup("\e[31mHello\tWorld!\e[0m");
	    AllocTag_dynamic_description(a, "strdup: \""
	        << libcw::debug::buf2str(a, strlen(a)) << '"');
	  will print 'strdup: "\e[31mHello\tWorld!\e[0m"' as description.

	  Added a new macro: RegisterExternalAlloc(ptr).
	  This macro calls libcw::debug::register_external_allocation(ptr)
	  unless --disable-libcwd-alloc was used during configure; then the
	  macro is empty.  This function allows one to register an external
	  allocation so it can now can be reallocated or freed by the
	  application (as well as externally).  Magic numbers are not added
	  because that would need a realloc (and thus a pointer change) and
	  it would break the case where the external library would occasionally
	  free the allocation again. ]

libcwd-0.99.9

	template<typename T> type_info_of<T>(void) was changed so that it no
	longer ignores any top-level qualifiers (in example,
	type_info_of<A const&>()); when using g++ 3.0.  Note that 0.99.8 still
	ignored those (including a `const') despite the release notes saying
	it didn't.

	The signature of template<typename T> type_info_of<T>(T) has been changed into
	template<typename T> type_info_of<T const&> in order to allow it to be used for
	abstract objects and/or objects with protected constructors.  This also avoids
	that a copy constructor for type T is called.  This version of type_info_of
	*does* ignore the top-level qualifiers (just like typeid() does).

	demangle_type(char const* in, std::string& out) now can be passed a string `in' that
	is not zero terminated.  This allows to demangle types in the middle of a mangled
	name without first copying the type (which is often impossible because you don't know
	what the type is in the first place).

	A new demangler was added for g++-3.0 and higher (the new ABI).  This took me weeks
	and weeks of hard work!

	class channel_ct has a new method: initialize(char const* label).  This allows one
	to pre-initialize a debug channel in the emergency case that it is needed before
	the constructor of this global object is called.  All global objects that libcwd
	declares are initialized this way when either `libcw_do' is constructed, or at the
	first call to new/malloc.

libcwd-0.99.8

	This version now also compiles and works with g++ 2.95.3 and
	3.0 20010523 (prerelease).  Demangling of variables and types with
	g++ 3.0 is still not implemented however.

	As a result of how libstdc++-v3 works, I've been forced to make all
	allocations done inside Dout() `internal'.  This has as disadvantage
	that memory allocations that are allocated inside Dout (in the user
	program; for example: Dout(dc::foo, malloc(1)))  but never freed
	will leak memory unnoticed.  Freeing this memory later, outside Dout(),
	currently leads to the rather confusing error:

	  COREDUMP: Trying to delete[] a pointer (0x80525d8) that appears to be internally
	  allocated!  This might be a bug in libcwd.  The magic number diagnostic gives: You
	  are 'delete[]'-ing a pointer (0x80525d8) that was allocated with 'new[]' internally
	  by libcwd.  This might be a bug in libcwd.

	template<typename T> type_info_of<T>(void) was changed so that it no
	longer ignores a top-level `const' (in example,
	type_info_of<A const>()); except on g++ version 2.96 (RedHat) which
	has a bug that causes this `const' still to be ignored.

	Several bugs were fixed that caused libcwd not to compile when the
	more exotic configure options, like --disable-*, were used.

libcwd-0.99.7

	This version compiles with g++ 3.0 20010224 (prerelease).  That is of
	little use however because it still doesn't work with libstdc++ version 3
	(some serious rewriting seems to be needed for that :().  Also note
	that this version is (still) not Thread-Safe.

	Removed the compile option "-fno-exceptions" as default,
	the library now also compiles without it.

	Removed libcw/h.h.  The library now does not include namespace std
	anymore by default and was patched to also compile in that case (this
	worked anyway already but is needed for g++-3.0).

	API changes:

	Support for the macro Dout_vform has been removed because
	ostream::vform isn't conforming the standard and is gone in
	libstdc++ version 3.

	libcw::debug::find was renamed to libcw::debug::find_channel.

	Bug fixes:

	g++-2.95.x core dumped in lockable_auto_ptr.h.  This is the reason
	for the release of 0.99.7.

	Improvements in acinclude.m4: some tests where done with the C++
	compiler and failed when using a compiler in a non standard place.
	Other tests failed because they use exit() without a proper proto-
	type.

	Fix in the testsuite so it also works when using a compiler that is
	installed in a non-standard place.  You still need to add the path to
	libstdc++-3.so to your LD_LIBRARY_PATH however!

libcwd-0.99.6

	A little gadget was added to namespace libcw::debug `cwprint_using'.
	This template function can be used to print objects to a debug
	stream using a method like `void print_on(ostream&) const'.
	Example usage: Dout(dc::notice, "object is: " <<
            cwprint_using(object, &Object::method) << '.');
        which then calls `void object.method(ostream&) const' to print data
	to the debug ostream.  When variations to this trick are needed
	then you can obviously add those to your local debug.h file.

	It is now allowed to use -DCWDEBUG instead of -DDEBUG while compiling
	files.  This allows to use the macro DEBUG for something else.  The
	use of -DDEBUG is deprecated, please switch to CWDEBUG.

	API changes:

	Major namespace changes:
	Almost everything was moved to namespace libcw::debug.
	This means that you probably will need to add a
	`using namespace libcw::debug;' to your local debug.h file.
	Note that namespace libcw::debug is automatically included in Debug()
	and Dout() et al; however due to a bug in the compiler this sometimes
	doesn't work and you still have to explicitely give a namespace.
	The following functions are still in global namespace when DEBUGMALLOC
	is defined:
	  __libcwd_malloc(unsigned int)
	  __libcwd_calloc(unsigned int, unsigned int)
	  __libcwd_realloc(void*, unsigned int)
	  __libcwd_free(void*)
	  template<typename T> T* __libcwd_allocCatcher<T>
	and it still redefines operators new and delete of course.
	The following templates are defined in namespace libcw:
	lockable_auto_ptr<>, manip1_tct<>, manip2_tct<>, imanip_id_tct<>,
	get_imanip_data<>, get_omanip_data<> and omanip_id_tct<>.
	These are defined in the header files libcw/lockable_auto_ptr.h and
	libcw/iomanip.h (they are actually part of libcw but also included
	with libcwd because libcwd uses them internally).
	[ Use "using namespace libcw::debug;" ]
	[ "lockable_auto_ptr"        --> "libcw::lockable_auto_ptr" ]

	The bfd interface has been redesigned:
	- The global structure `location_st' has been removed and is replaced
	  by a class `location_ct' (in namespace `libcw::debug', see above).
	- The function `libcw_bfd_pc_function_name' has been renamed to
	  `libcw::debug::pc_mangled_function_name'.
        - The function `libcw_bfd_pc_location' has been completely removed.
	  Instead you should use the constructor location_ct(void const* addr).
	If you used any of this then you will need to recompile your programs.
	There is no danger to make errors: things are garanteed to not compile
	until you fixed them except for the following changes in functionality
	of the function name pointer as returned by location_ct::function():
	- The function name pointer as returned by
	  location_ct::mangled_function_name() is now the same as what is
	  returned by pc_mangled_function_name (This makes it unnecessary
	  to call pc_mangled_function_name after pc_location failed, in the
	  hope that that will work).
	- It is now possible to check if the function that is returned is known
	  by comparing the returned function name pointer with
	  `libcw::debug::unknown_function_c' (instead of needing a strcmp()).
	- `pc_mangled_function_name' also returns
	  `libcw::debug::unknown_function_c' on failure and not NULL as did
	  `libcw_bfd_pc_function_name'.
	[ "location_st" --> "libcw::debug::location_ct"               ]
	[ "libcw_bfd_pc_function_name(addr)" -->
	               "libcw::debug::pc_mangled_function_name(addr)"
	               (and doesn't return NULL anymore)              ]
	[ "location_st location; libcw_bfd_pc_location(location, addr);" -->
	  "libcw::debug::location_ct location(addr);"                 ]
	[ Available interface of location_ct: see libcw/bfd.h         ]

	A few functions have been renamed now they were moved inside the
	libcw::debug namespace:
	The class debugmalloc_marker_ct was renamed to just marker_ct.
	The function libcw_debug_move_outside was renamed to move_outside.
	The function debug_mem_size was renamed to mem_size;
	The function debug_memblks was renamed to memblks;
	[ "debugmalloc_marker_ct"    --> "libcw::debug::marker_ct"    ]
	[ "libcw_debug_move_outside" --> "libcw::debug::move_outside" ]
	[ "debug_mem_size"           --> "libcw::debug::mem_size"     ]
	[ "debug_memblks"            --> "libcw::debug::memblks"      ]

	The macro ASSERT(x) no longer contains a ';', this might mean that you
	need to add semi-colons yourself if you have been using it.
	[ "ASSERT( i == 1 )"         --> "ASSERT( i == 1 );"          ]

	Bug fixes:

	Fixed demangling `const' member functions aka:
	  void Foo::foo(void) const;

	There was 'static initialisation order fiasco' bug that appeared
	mainly on solaris (linux always first initializes the shared
	libraries and only then constructs global objects of the application).
	The bug occured in most cases when a memory allocation was done in the
	constructor of a global object while the global objects of libcwd were
	not initialized yet.  The main problem was that a debub object
	(libcw_do) was NOT turned off before initialisation.  This fix allows
	the use of malloc/new (of course), Dout and DoutFatal before libcwd
	is initialized.  Other libcwd functions can cause a core dump when
	used in constructors of global objects.

libcwd-0.99.5

	The prototype of libcw_bfd_pc_location was changed from
	location_st libcw_bfd_pc_location(void const* addr) into
	void libcw_bfd_pc_location(location_st& result, void const* addr).

	Support for openBSD was finished: it is now possible to
	compile a static library.  Unfortunately, it is still not
	possible to compile a shared library on this OS.

	Writing "DoutFatal(error_cf, ..." is no longer allowed, it now
	is required to explicitely add the debug channel and write
	"DoutFatal(dc::fatal|error_cf, ...".

	Added support for libtool-1.3c and higher (cvs developer version).

	Bug fixes:

	Fixed a problem related to reentrance of bfd_find_nearest_line
	(of libbfd) under certain circumstances, causing a copy of
	uninitialized memory.

	Removed a few compile warnings for g++-2.96.

	The order of debug channels in a `ForAllDebugChannels' is no
	longer dependant of the order of initialisation of the global
	debug channel objects (they are now alphabetically ordered on
	label).

	Fixed the generation of nodebug.h in the example project to remove
	the replacement-lists too after turning #defines into #undef.

	Now using the namespace of std::type_info in libcw/type_info.h.

	Lots of bug fixes and additions in the demangler.

libcwd-0.99.4

	A real testsuite was added, based on dejagnu.

	We depend more on libtool now to handle linking with shared or
	static libraries.  As a result you can (again) on linux, link
	with just -lcwd (without having to specify also -lbfd -liberty).

	Bug fixes:

	A locked lockable_auto_ptr would still transfer ownership
	when using the assignment operator.  IMPORTANT: API change:
	now a locked lockable_auto_ptr does NOT transfer ownership
	when using the assignment operator (as was documented).

	Libcwd got into an endless loop when a fatal error occured
	before the fatal debug channels where initialized.  This
	happened for instance when a hard limit for the core size
	is set.

	When a hard limit for the core size is set, the call to
	setrlimit failed and libcwd terminated with a fatal
	error (and got into a loop, see above).  Now it sets the
	core size to the maximum value and prints a warning when
	that isn't unlimited.

libcwd-0.99.3

	A different bug work around for the compiler bug that surfaces
	in iomanip.h has been used.  It turned out that not only
	gcc-2.95.2 but even snap shot 2.96-20000724 has problems with
	the (ISO C++ correct) construct that was used.  The new
	work around works better and is not any longer dependend on the
	value of CXXFLAGS.

	Support for solaris has been added.  Tests were done on a 
	sparc-sun-solaris2.7.

	Configuration and installation has been improved on FreeBSD,
	it should now compile 'out of the box' with the usual
	"./configure; make; make install".
	
	It is not necessary to use GNU make any longer when using the
	tar ball distribution (GNU make is still needed if you use
	cvs or --enable-maintainer-mode).

libcwd-0.99.2

	Configuration is now automated, using autoconf.  This removes
	the need to install the prototype package.

	The Internal Compiler Error in debugmalloc.cc has been isolated
	and a workaround has been added.  Whether or not the workaround
	is needed is detected by ./configure (but be warned: it depends
	on the CXXFLAGS you use, this bug only occurs when using -ggdb).

	A new function `Debug( check_configuration() )' was added.  Use
	it to assure that the configuration of the linked library matches
	the configuration of the header files used.

	demangle.cc was completely rewritten.  It now exports two functions:
	`demangle_type' and `demangle_symbol', the latter is a replacement
	for the `cplus_demangle' from libiberty.  This allows to link with
	the shared version of libiberty (needed by libbfd) which was needed
	on FreeBSD.  This also gets rid of any direct dependence of libcwd
	on libiberty, which wasn't good because libiberty is not compiled
	with -fPIC.

libcwd-0.99.1

	Support for FreeBSD (4.0)
	Improved bfd.cc a little (lookup of symbols and source:line info)
	Minor bug fixes

libcwd-0.99.0

	First public release
