www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/11/04/09:23:02

Date: Tue, 4 Nov 1997 16:20:35 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Paul Derbyshire <ao950 AT FreeNet DOT Carleton DOT CA>
cc: djgpp AT delorie DOT com
Subject: Re: ELF-binary format object file?
In-Reply-To: <63jqeh$nu2@freenet-news.carleton.ca>
Message-ID: <Pine.SUN.3.91.971104161528.20360B-100000@is>
MIME-Version: 1.0

On 3 Nov 1997, Paul Derbyshire wrote:

> >        - The shared library includes ALL of libc, so if the loader
> >          loads it in its entirety, you actually *waste* memory (since
> >          it's a rare program that uses all of the libc).
> 
> Not if each .o of libc is dynamically-linked independently the way they
> are now statically linked independently.

I don't believe this is possible.  Do you know about an object format 
supported by GNU Binutils that makes this possible?

> That is a potential problem. The solution is to let older programs
> continue to use the static library version built in, and to ensure that
> any and all shared libraries:
> a) are distributed as bug free as possible

Ha!  The one that achieves this should get a Nobel prize!

Besides, patches to libraries are not only bugfixes, quite a few of them 
are enhancements.  You don't want to stop development, do you?

> b) are always backward compatible when new versions come out, so new
>    versions can be written over old ones without breaking anything, and users
>    need only keep a single copy on their disks.

This is impossible in practice, IMHO.  The only way to achieve it is by 
bloating the code with compatibility wrappers, and given the many 
different versions that we would like to support, this would be a *real* 
bloat.  Which of course again defeats the very reason for shared 
libraries.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019