From owner-freebsd-current  Fri Sep 22 07:23:23 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id HAA04885
          for current-outgoing; Fri, 22 Sep 1995 07:23:23 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA04866
          for <freebsd-current@FreeBSD.org>; Fri, 22 Sep 1995 07:22:39 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA10070; Sat, 23 Sep 1995 00:14:43 +1000
Date: Sat, 23 Sep 1995 00:14:43 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199509221414.AAA10070@godzilla.zeta.org.au>
To: bde@zeta.org.au, rich@lamprey.utmb.edu
Subject: Re: XFree86 and the new malloc
Cc: freebsd-current@FreeBSD.org, roberto@keltia.Freenix.FR
Sender: owner-current@FreeBSD.org
Precedence: bulk

>|From: Bruce Evans <bde@zeta.org.au>
>|
>|>Has anyone tried to   link the X server  with  the new libc's  malloc  from
>|>Poul-Henning ?
>|
>|It's already linked to libc's malloc unless you have a version that is
>|linked to a nonstandard libmalloc.  This is one of the main advantages
>|(?) of not putting phkmalloc in a special library that almost no one
>|will use.  It also shows why third party programs should not use
>|nonstandard libraries to avoid problems in standard libaries.

>Hey, wait a sec.  XFree86 3.1.2 does use -lgnumalloc.  We
>had been testing it but only switched when it passed all the
>alpha/beta tests, and that happened after 3.0 came out.

Yes, XFree86 3.1.2 is linked to a nonstandard malloc.  This unfortunately
means that people running the newest versions of everything, so that they
have phkmalloc, the latest Xfree, and sig11's (:-), won't automatically
be testing phkmalloc where testing/use is most important/beneficial.

FreeBSD-2.0.5 only has Xfree 3.1.1.  I don't use X much, and 3.2.2 doesn't
work here (*), so I just use the version of the cdrom.

(*) The W32 version used to hang waiting for a bit in ACL_ACCELERATOR_STATUS,
always after switching the console back to X and sometimes at startup.  In
3.1.2, it aborts early in initialization related to this when it references
an uninitialized ACL_ACCELERATOR pointer.

Bruce