Adam P. Harris wrote:
> "Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
[linking shared libraries against other libraries]
> > As far as I can tell, it does not save disk and memory space.
> > However, I am rather new at this. Feel free to correct me.
>
> You are wrong. Shared libraries are able to use copy-on-write memory
> space (hence the 'shared' category when you type 'free') which can
> radically lower RAM requirements. This is not the case on statically
> linked libraries.
I think there is a confusion of terms here. This is not about linking
shared vs. static. But it's easy to get that idea, because when ldd
is run on a library that is not linked with anything else, you get:
% ldd /usr/lib/libdpkg.so.0.0
statically linked
But this is not true!
libdpkg does not include code from any other library. Symbols like
sprintf are left unresolved. Any program that is dynamically linked
with libdpkg must also be dynamically linked with a libc that provides
these symbols, so that they can be resolved at program startup time.
This is described in
ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz
particularly section 5.4.
If libdpkg were compiled with -lc, then the soname of the libc it was
linked with (i.e. libc.so.6) would be listed in its dynamic
dependencies. This means that when the dynamic linker links in
libdpkg, it also links in libc.so.6. Thus, you can't accidentally
combine libdpkg with the wrong libc version.
(gcc adds -lc by default when compiling a program, but not when compiling
a shared library.)
So you see, the code is shared either way. The point of this release
goal is to put explicit dependency information in the shared
libraries.
Richard Braakman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
