From owner-freebsd-hackers  Sat Jun 24 07:47:28 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id HAA10713
          for hackers-outgoing; Sat, 24 Jun 1995 07:47:28 -0700
Received: from id.slip.bcm.tmc.edu (root@hou31.onramp.net [199.1.137.159])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA10707
          for <freebsd-hackers@freebsd.org>; Sat, 24 Jun 1995 07:47:25 -0700
Received: by id.slip.bcm.tmc.edu (8.6.11/1.34)
	id JAA03561; Sat, 24 Jun 1995 09:46:53 -0500
Date: Sat, 24 Jun 1995 09:46:53 -0500
From: rich@id.slip.bcm.tmc.edu (Rich Murphey)
Message-Id: <199506241446.JAA03561@id.slip.bcm.tmc.edu>
To: dawes@physics.usyd.edu.au
CC: freebsd-hackers@freebsd.org
In-reply-to: <199506240656.AA02226@physics.su.oz.au> (message from David Dawes on Sat, 24 Jun 1995 16:56:12 +1000 (EST))
Subject: Re: Memory leak somewhere?
Reply-to: rich@lamprey.utmb.edu
Sender: hackers-owner@freebsd.org
Precedence: bulk

|From: David Dawes <dawes@physics.usyd.edu.au>
|>XFree86 used to link the binaries against -lgnumalloc by default in
|>earlier versions.  NetBSD still does.  Is there any reason why it has
|>been dropped for FreeBSD?  (I think gnumalloc falls under LGPL, so the
|>Copyright issues aren't so hard here.)
|>
|>At least for the server, it seems to be a big deal.  I used to link
|>mine against the GNU version, and now that i didn't do it for the
|>first time, i'm seeing it growing rather large, too.
|
|It was dropped because someone reported problems with it.  I've been
|using it for the last few weeks without problems though, and I'm
|planning to link with gnumalloc by default for FreeBSD in XFree86
|3.1.2.
|
|Regarding LGPL, there is no problem for the Xserver because we have
|the LinkKit.
|
|I don't know about clients, etc, or how LGPL fits in with dynamically
|loaded libraries (I'd have expected dynamic linking to fulfill the
|requirements of LGPL).  Anyway, this is an issue for those distributing
|binaries.  We (XFree86) provide full source, so there isn't any problem
|for us.

When FreeBSD had two separate malloc shared libraries we had
a XFree86 release which could use either malloc library simply
by swapping the names.  Substituting libgnumalloc.so.1.1 for
libmalloc.so.1.1 worked just fine for the server.  But this
was only my individual testing and nothing rigorous.

We don't really know whether the problems last year using
gnumalloc were due to valid differences in the API or
unwitting problems in the server itself.  But we can start
beta testing with gnumalloc and see how it goes.  Rich