Re: Debian 2.0 release requirements
> Shared libraries are linked dynamically against other libraries
>
> Linking shared libraries dynamically against other libraries
> simplifies the upgrading process and saves disk and memory space.
> All shared libraries included in the Debian distribution will be
> compiled that way.
>
> See H.J. Lu's `ELF: From The Programmer's Perspective' for
> details.
I don't think the rationale is correct. H.J. Lu's paper makes it
clear that the point of linking a library this way is to tell the
dynamic linker which other libraries are used by this library.
It does not change the way the library is compiled.
Linking shared libraries against the libraries they use has
three advantages:
- It allows the dynamic linker to give warnings when incompatible
libraries are mixed.
- When compiling a program, the linker can automatically link in
the extra libraries that are used by the libraries that were
specified on the command line. (Thus, you can link with
tk without explicitly adding -ldl and -lm).
- It gives dpkg-shlibdeps enough information to generate the
correct dependency information for a package that contains
shared 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.
> All binaries in ELF format (no a.out binaries)
>
> Though, ELF has been Debian's default binary format for few
> releases now, a.out development packages have still been provided.
> As a.out binaries have become rare lately, the development tools
> for this binary format has been dropped.
>
> However, run-time support for a.out binaries is still available.
If we have no a.out development tools, how will we compile the
runtime support for a.out? The runtime support packages would
have to go into contrib.
Richard Braakman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: