From: Godmar Back (gback@cs.utah.edu)
Date: Tue Jan 26 1999 - 22:11:14 EST
>
> On Jan 27, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>
> >> that selectively drop libraries, or (after my last patch) that the
> >> full list of dependencies has been dropped, in the mechanism used for
>
> > Call me dumb, but you point out where in the following jumbolog
> > it says the list of dependencies that could not be satisfied?
>
> The `after my last patch' sentence intended to mean that it would only
> print this message after I updated Kaffe's libtool suite, but that it
> was currently modified in the libtool CVS tree to print:
>
>
So even the current libtool version, once integrated in Kaffe, will
only tell me this warning:
> *** Warning: inter-library dependencies are not known to be supported.
> *** All declared inter-library dependencies are being dropped.
and not what the actual missing dependencies are? I'm confused...
> > Secondly, what exactly does it mean for a system to support "inter-library
> > dependencies"?
>
> There are various levels of support to inter-library dependencies.
> The main point is to be able to know whether it is possible specify a
> dependency library in the link command of a shared library, and if
> this will cause the dependency library to be implicitly
> opened/dlopened whenever the dependent library is.
>
> Some platforms can do that with with static (by copying of imported
> symbols) and shared (through dynamic dependency) libraries. Some
> require the dependency library to be shared; others don't require
> this, but will silently copy unusable (non-PIC) parts of static
> libraries into a shared library, and crash only at run-time. Some
> will only support one level of inter-library dependencies (i.e., if
> b.so depends on c.so and a.so is linked with b.so, c.so won't be
> loaded), and some just don't support inter-library dependencies at
> all. More details can be found at
> http://www.gnu.org/software/libtool/deplibs.html
I had read that page before. I think I now understand better what
you're talking about here.
Let me tell what I find one of the most confusing things about libtool,
and think about whether you should update your documentation to take
these comments into account.
1) When you talk about a dependency, you mean that a library libfoo depends
on libbar, for instance, because the shared library system on which you're
running allows you to do that, or even requires you to say how to resolve
undefined symbols in libfoo when creating an .so file for libfoo.
With libtool, you specify -lbar when creating libfoo.la, and libtool
will record that "dependency".
2) When I talk about a dependency, I mean that a library libfoo references,
but does not define a symbol 'f'. libfoo depends on 'f', or better, it
depends on an definition of 'f' in any .o file that's either part of
the final executable or loaded at run time. If there's a library
libbar that happens to define 'f', I say that libfoo depends on libbar,
or that libbar is a dependency of libfoo. Only if I'm running on a
system with shared libraries that requires me to do so should I have to
declare that libbar defines 'f' when building libfoo. On all systems,
such as when I use static libraries, I should not have to declare
that I intend to resolve 'f' from libbar when I build libfoo. Instead,
I should be able to build libfoo by itself. Later on, when I create
an application, I can decide that I want to resolve 'f' from libbar,
or from any other location. Why does libtool require me to say where
I want to take 'f' from if that *only* applies to static libraries?
I find this somewhat fundamental, and you should make very clear what
kind of dependencies you're talking about.
The reason why I defined dependency the way I did in 2) is libtool's premise
that it wants to treat shared and static libraries alike. However, static
libraries do not have the notion of dependencies you specify in 1).
Hence, inter-library dependencies, as you view them, are very much specific
to shared libraries, and have nothing to do with static libraries at all.
Libtool, however, by adding the object modules of a "dependent" library
to the object modules of the library referencing it in the way defined in 1,
attempts to simulate the way shared libraries are linked for static libraries.
This may make sense from the premise to treat them alike, but another view
to look at this is that it attempts to treat static libraries as something
that they are really not. It is in contrast to the simple and
well-understood concept of a library being an archive of .o files, however
fragile that concept may be in other cases I pointed out.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:49 EDT