Re: Including static libraries in shared libraries with libtool.
Howard Chu wrote: One more time, shouting into the senseless void... If these so-called convenience libraries are meant to be linked in whole, they should not be ar archives at all. You should just link them directly into a relocatable object file: ld -r -o convenience.obj *.o I am listening, and I have taken this under advisement, and plan to start the transition to reloadable objects after the dust on 2.0 has settled. Thanks for persevering with us. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Including static libraries in shared libraries with libtool.
Hi, My intentions here are: Build the sources for libauthuserdb.la. Take their object code, and grab whatever modules from libauth.la that are references by stuff in libauthuserdb.la, and place all of that into a shared library. Not possible without reimplementing parts of the linker. Parts of static libraries cannot be linked into shared libraries, as shared libs need to be compiled as position independent code (ld.so on ix86 linux can work around that by mapping the offending library into a private mapping and relocating it, but that is a huge waste of memory and not portable). Unfortunately, the actual results are different. There are two problem: 1. Libtool takes _all_ modules from libauth.la, and puts them into libauthuserdb.la. I only want the modules that libauthuserdb.la actually needs. A convenience library, as a libtool library that is not installed is called, is linked into each object that uses it. If the object is a library, it is copied completely, otherwise, it is linked statically. This feature is intended for huge libraries that are built from multiple subdirectories, where each subdir builds a convenience lib and everything is linked in the end. 2. For some reason, only the static version of libauthuserdb.la is generated. I don't know why, but libauthuserdb.so is not created, only libauthuserdb.a is created. I am _not_ using the --disable-shared flag with the configure script. There is no way to build a shared library, as parts of it are only available as non-PIC code. However, this is not practical. I'm building several shared libraries that use different bits and pieces of the common code, and manually tracking which common source module is used by which shared library is cumbersome. I need to coerce libtool in doing this job for me. If there may be additional shared libs that may be built outside of the source tree, you may be better off making a ...-util library that is installed and linked by all of your other libraries. This is transparent to the user, but permits everyone to write their own libraries linking against the -util library. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 signature.asc Description: Digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Including static libraries in shared libraries with libtool.
Simon Richter writes: Hi, My intentions here are: Build the sources for libauthuserdb.la. Take their object code, and grab whatever modules from libauth.la that are references by stuff in libauthuserdb.la, and place all of that into a shared library. Not possible without reimplementing parts of the linker. Parts of static libraries cannot be linked into shared libraries, as shared libs need to be compiled as position independent code (ld.so on ix86 linux can work around that by mapping the offending library into a private mapping and relocating it, but that is a huge waste of memory and not portable). I can create a static library from PIC modules that libtool already builds. It actually turns out to be fairly easy: libshuserdb.a: libuserdb.la -rm -f $@ cd .libs $(AR) $(ARFLAGS) ../$@ $(libuserdb_la_OBJECTS:.lo=.o) If there may be additional shared libs that may be built outside of the source tree, you may be better off making a ...-util library that is installed and linked by all of your other libraries. This is transparent to the user, but permits everyone to write their own libraries linking against the -util library. Let's explore this possibility. I have about a dozen small components (a component=library) other. Each component is in its own subdirectory. It can be built, if necessary, by itself. The components are not installed, they are just building blocks. Then, there are several installable shared libraries. Each shared library makes use of various bits and pieces from various component libraries. Your suggestion, as I understand it, is to take all the small component libraries and put them together into a single -util, that every installable shared links against. Fair enough, bit libtool doesn't seem to be able to do that. libutil_la_SOURCES=[ file listing ] libutil_la_LIBADD=subdir1/libcomponent1.la subdir2/libcomponent2.la From what I can see, libtool is not going to add libcomponent1.la and libcomponent2.la to the shared version of libutil.la, it will merely record their SONAME, and I still have to install libcomponent1.so and libcomponent2.so, in addition to libutil.so. Now on the static side, it looks like libtool will methodically unpack libcomponent1.a and libcomponent2.a; then put all of the extracted modules into libutil.a, together with libutil.a's own object modules, so libutil.a has everything. That, pretty much, is what I need to do with the shared library version as well. My component libraries are logically grouped, and each one is dedicated to a specific functionality. I'd rather not break everything up, and manually force everything into libutil.so, making for a big mess. pgpkGx0DsKG4o.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Including static libraries in shared libraries with libtool.
On Sun, 26 Sep 2004, Simon Richter wrote: 1. Libtool takes _all_ modules from libauth.la, and puts them into libauthuserdb.la. I only want the modules that libauthuserdb.la actually needs. A convenience library, as a libtool library that is not installed is called, is linked into each object that uses it. If the object is a library, it is copied completely, otherwise, it is linked statically. This feature is intended for huge libraries that are built from multiple subdirectories, where each subdir builds a convenience lib and everything is linked in the end. Using recent Automake, I find that I am able to eliminate use of convenience libraries by using a non-recursive build and referring to sources in subdirectories. A simple Automake macro refers to all the objects which would be equivalent to a convenience library. Works great and avoids the overhead imposed by libtool since libtool must extract all the objects from the archive file prior to using them. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
