Re: libc5 policy decision - FYI
On Fri, 1 Nov 1996, Bruce Perens wrote:
>From: Guy Maor <email@example.com>
>> Since the number of packages that don't work with the old allocator is
>> very small, 2 confirmed so far, this doesn't really make sense. What
>> would make sense is to build 5.4.7 with malloc-dl, and make the old
>> malloc available as a separate library.
>> In other words, the default behavior should be the new malloc,
>> Would you reconsider?
>I will reconsider and go along with your proposal,
>but I reserve the right to revisit this question ten days before release.
>If at that time it's clear that wrappers have not been constructed for the
>problem packages and stability _is_ a problem, I will ask for the old
>allocator to be put back, and the new one moved into a separate library.
I just wanted you to know that I have been using libc5.4.7 here for a few
days now and have _no_ problems with it. Now, let me tell you why I
I had a debian 1.1 install with libc5.2.18 and all the development libs.
Someone had told me a while back that linux didn't free() memory properly,
and that it wasn't really freed until the program exited. So I wrote a
simple program that malloc()'d a given amount of memory, then paused, (so
I could see how much ram it used), then free'd after you hit a key.
5.2.18 would not actually free the memory. cat /proc/meminfo still showed
the full amount of memory in use, as did ps -apm
5.4.7 worked as expected.
A friend of mine was running libc5.3.something and it also worked fine on
Note that just installing the shlib for libc5.4.7 did not correct the
problem. I had to install the libc5.4.7-dev and recompile for it to work.
I have the source for this little program here. If you'd like to see it
just send me a mail ;)
Just thought I'd let you know.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com