From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Wed Jan 27 1999 - 00:11:35 EST
On Jan 27, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>> Yes, the actual dependencies will be the ones listed in the libtool
>> command line.
> What if only some of them are unresolved, but others are not?
> For instance, if I create libfoo with -lbar and -lbaz, but only
> -lbaz could not be found, how will it tell me?
In the case of FreeBSD2 a.out, the current libtool won't even look for
libraries, it will just drop all dependencies. On systems such as
Linux and Solaris, that use file_magic to pick only shared libraries
in dependency lists, it will list all libraries for which it couldn't
find a shared version, then summarize with the final warning message
that you already know.
>> It only does that for convenience libraries, and then, it does it for
>> both shared and static libraries. object modules of inconvenience :-)
>> libraries are never copied into another library (except when libtool
>> is allowed to pass static libraries in the link command line of a
>> shared library and the shared library linker copies some of its object
>> modules into the shared library on its own)
> Alright. I'll stop complaining. I think my point is made.
> Read your last sentence back to you and then maybe you can see why
> I think that libtool is a typical example for a tool that tries
> to fight complexity with even more conventions, rules, and options.
Jeez!, you wouldn't have to understand it all, but you asked for the
details. It is complex, but libtool makes it simple! Do you really
think that adding -lname switches to a command line when you want to
declare that a library imports symbols from another is so much
complexity?
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:49 EDT