Re: Linking problem

[Ralf Wildenhues]

Sorry for the self-reply.

* Ralf Wildenhues wrote on Thu, Oct 27, 2005 at 08:54:29AM CEST:
> * Nitesh Soni (NC/TNT) wrote on Wed, Oct 26, 2005 at 11:53:32PM CEST:
> > 
> > I am using libtool to build static and shared libraries. Now, I have
> > run into the following problem.
> > 
> > Lets say I am building a library "libX.la". This library is a
> > collection of other libraries and NO source files.  Eg.
> > 
> > In my Makefile.am I have something like:
> > 
> > libX_la_SOURCES = 
> > 
> > libX_la_LIBADD = libY.la
> > libX_la_LIBADD += libZ.la
> > 
> > Now, when I build this library using libtool, I get the following output: 
> > 
> > libtool --tag=CC --mode=link gcc -o libX.la libY.la libZ.la
> > 
> > gcc -shared -o.libs/libX.so .libs/libY.so .libs/libZ.so
> > 
> > ar cru .libs/libX.a
> > ranlib .libs/libX.a
> > 
> > As you can see, its building the shared library but not the static archive.
>
> - Are libY.la and libZ.la convenience archives or to-be-installed
>   libraries?  I.e., in Automake terms, are they noinst_LTLIBRARIES
>   or something else?

To be more precise: if both libZ.la and libY.la are convenience archives
(noinst_LTLIBRARIES), their contents should be added to libX.  If
instead they are installable libraries (lib_LTLIBRARIES, for example),
only the _dependency_ information should be added to libX, but not the
contents. And this what you see happening: libX.la will contain
references to libX and libZ in its dependency_libs entry in this case.
If that were any different, then a program linking against both libX
and, say, libZ, may possibly encounter duplicate symbols, so linking
may fail.

OTOH, this makes me wonder whether your example is maybe not portable:
creating a libtool archive that has no SOURCES and links only against
installable libraries may fail on some systems .. I need to go and check
this.  It likely isn't what you intended to do anyway.

Cheers,
Ralf