Mail Archives: djgpp/1997/11/05/10:32:44
Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) writes:
> 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?
Sure. Split libc into separate dlx's along the lines of the original .o
files. Dynamically link each separately, as needed.
>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.
Are you sure we're talking about libc here? The interface of libc is
specified mostly, in the ANSI standard, what rest there is is documented
too. As long as the functions are called the same way and return the same
stuff with the same semantics, the inner guts can be debugged or optimized
to your hearts' content without breaking old code that calls the libc
functions.
--
.*. Where feelings are concerned, answers are rarely simple [GeneDeWeese]
-() < When I go to the theater, I always go straight to the "bag and mix"
`*' bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh
- Raw text -