RE: Changes in handling library dependencies
> No, this is wrong. With dynamic linking it is proper to
> specify ONLY the
> libraries whos functions you explicitly use. For instance if
> you only call
> imlib functions then you should link only to imlib. In turn, imlib's
> shared library can link to or dlopen whatever other shared
> libraries it
> requires. Try running ldd on a shared object and you can see this, for
> instance,
>
> b54pc18{jgg}~#ldd /usr/lib/libgtk.so
> libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0
> (0x40124000)
> libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40127000)
> libdl.so.2 => /lib/libdl.so.2 (0x40149000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4014d000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40159000)
> libm.so.6 => /lib/libm.so.6 (0x401fd000)
> libc.so.6 => /lib/libc.so.6 (0x40219000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
>
> For dynamic libraries you should be able to link with a minimal set of
> libraries, ie to use GTK you should not need to include X libraries
> (unless you use X calls) and so on.
>
> *static* libraries are conisiderably different and in that case you do
> need to mention all of the libraries that all of the sub
> libraries touch.
> However, I thought gnome used libtool which takes care of
> that through its
> .la files, making this whole point moot.
Hmm, I come from the time that you needed to do all the magic stuff to
make your libraries dynamically loadable by yourself. In those days you
had to request an address to load your library. Things have come quite a
ways since then. But I digress.
Anyway, on a lot of architectures it is still the case that you have to
specify all the libraries that your program uses, including the ones
that the program is only implicitly dependent on. Unless of course the
library is sufficiently smart that it only loads those functions it uses
on demand (dlopen() and friends). The way that it used to work is that
for shared libraries all symbols of a .so file would reside in a .sa
(shared archive) file, which was treated as .a files would be. If it is
indeed the case that the linker now only uses the .so files and then
automagically knows what other symbols are needed to be pulled in, then
I can only say: great. Just keep in mind that this does not work on all
systems - but maybe that does not apply to the architectures (linkers
really) that Debian caters to.
I hope this clarifies my original statement somewhat; if the linker only
needs the direct libraries with the symbols used, great; in that case
the dependencies of the program will indeed correspond directly to the
libraries used, which, if they have their dependencies in order, ensure
that their libraries are present as well.
Ronald
>
> Jason
>
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
Reply to: