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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
