[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Including static libraries in shared libraries with libtool.

From: Howard Chu
Subject: Re: Including static libraries in shared libraries with libtool.
Date: Sun, 26 Sep 2004 15:43:29 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714

Bob Friesenhahn wrote:
On Sun, 26 Sep 2004, Simon Richter wrote:

1. Libtool takes _all_ modules from, and puts them into I only want the modules that actually

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.

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

The linker is faster, and it will resolve a majority of external symbol references immediately; i.e., all of the cross references between those .o files. Then when it comes time to combine all the convenience pieces into a single program, that step will also be faster and there's no wasted time extracting/deleting archive members.

And as a previous post points out, just because object files are stored in an archive library is no reason to assume they are non-PIC code and thus unusable. That was the whole point of the other thread - that there is no consistent way to check for PIC vs non-PIC in advance.

But again, if all you plan to do is link *all* of the objects together, e.g. for a shared library or for a "convenience" library, then you should just use "ld -r" and skip all the other intermediate crap.

This is REALLY REALLY basic ld usage practice, I'm really amazed that you guys keep inventing newer, harder ways to do things.
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun     
  Symas: Premier OpenSource Development and Support

reply via email to

[Prev in Thread] Current Thread [Next in Thread]