Patch to use Doug Lea's malloc

[Richard Earnshaw]

> I've had this in my personal tree for a while; I used to get strange
> crashes in free when using the system malloc that went away when I tried to
> debug them by linking against dlmalloc, and ended up leaving it.  Doug's
> malloc is also much more space-efficient than, say, Sun's, which makes a
> difference to a memory-hungry application like gcc.  Thoughts?
> 
> I also have #define DEBUG 1 at the top of the file in my personal tree, but
> that should probably be configured somehow for production use.  Again,
> thoughts?
> 
> Wed Feb 10 23:51:35 1999  Jason Merrill  <jason@yorick.cygnus.com>
> 
> 	* malloc.c: New file.
> 	* Makefile.in (OBJS): Add malloc.o.

Doing this in this way will break the build on RISC iX.  It is not 
possible to just override symbols in the C library without causing link 
problems.  There are similar problems with getopt, but we can work around 
them by just adding some #defines to create gnu_getopt and friends; this 
won't work with malloc, since there can be only one malloc in the program, 
and the C library needs to be able to call it as well.

Ideally there should be some autoconf test to see if we can build an 
executable this way.  If not, then I think there should be a MALLOC 
variable in the makefile, so that host fragments can define it away if it 
causes build problems.

Richard