Re: libc5 policy decision
When will maintainers be able to download this libc setup so that we can
get our packages compiled correctly. Would packages compiled against
5.4.7 have to be recompiled to work with this new setup.
On Fri, 1 Nov 1996, Bruce Perens wrote:
> > When will you be making the libc5 decision?
> > It would be nice to start Rex with the right one when it gets frozen.
> Here is the decision. Libc 5.4.7 will be used with the _OLD_ allocator
> in 1.2 .
> The _NEW_ allocator will be made available in a separate library, and
> people who want the increased performance of the new allocator will be
> able to set LD_PRELOAD=/lib/libNewAllocator.so.5 (change the name as
> appropriate) in their .login or .profile scripts, etc. Packages
> should be tested with the new allocator, but not linked in such a way
> that they demand it. This library will be made an empty stub in 1.3 so
> that it does not collide with LIBC 6. 1.3 will provide libc.5.4.7 and
> the old allocator for compatibility with old applications, and LIBC 6
> with whatever allocator it contains for everything else.
> I am aware that this is sub-optimal, and there's the esthetic problem of
> holding back the library to make up for broken applications. I would not
> make this choice if the release was to have an infinite lifetime.
> Can you get the above implemented in time?
> Pray tell, does the allocator in GNU LIBC 6 have anything to do with
> either of the allocators in libc 5?
> 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
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