These questions are quite common, and what they really come down to is that
many (or most) users want to solve a *different problem* than the one that
Libtool was designed to solve.

Libtool will deal with the platform specific vagaries of shared libraries
in a uniform manner.  It isn't designed to easily expose features of *some*
specific shared library implementions, but attempts to support the largest
common subset of features.
If you have a fairly simple packge that includes libraries, you may be able
to build & run it on CygWin with no changes (for example), and that is what
Libtool was designed to do.

Some that you mention below could be dealt with by adding them as new
features.

On Fri, Jan 6, 2012 at 12:31 PM, Peter O'Gorman <pe...@pogma.com> wrote:

> On 01/06/2012 11:21 AM, Stepan Kasal wrote:
>
>>
>> 1) .la file always contains the recursively evaluated list of libraries.
>> While this is necessary for static linking and dumb dynamic linkers,
>> it is an issue for dyn. linkers that can do recursive resolution
>> (which is the case on GNU/Linux distributions for many years).
>> (I believe that the rule that forbids packing .la files to -dev and
>> -devel subpackages on Debian and Fedora (respectively), is there just
>> to work around this problem.)
>>
>
> This is still an issue, libtool always adds all dependencies. Many
> packages assume this and don't explicitly add required dependencies to
> Makefile.am etc. I don't recall the arguments for not changing this when
> building shared. IIRC Scott tried to include Debian's patch at some point.
> I'll look it up in the archives later.
>
>
> Overlinking when using shared libraries is not a good thing, and Libtool
could be modified to have a list of all dependencies for the static case,
but when the platform supports it, it could also have a list with only the
first level of dependencies.


>> 2) People told me libtool is slow and shell has to parse huge script
>> just to find out that it has to call gcc twice, with and without
>> -fPIC.  Again, this is not about the general portability case, it is
>> a request for optimization on GNU/Linux platform, that they percepts
>> as one of the major customers of libtool.
>>
>
> Libtool is faster than it used to be, the shell does have to parse quite a
> bit of script, but compile mode has been moved as close to the beginning of
> the script as possible to reduce that time, and the number of forks has
> been reduced drastically for modern shells. I believe dash and ksh93 are
> faster than bash at running libtool. Last time I checked, libtool's compile
> mode wasn't significantly slower than using dolt (
> http://dolt.freedesktop.org/)**.
>
>
>
 This could be optimized even more, but it would be a considerable amount
of work just to speed up compilation (Shouldn't we be spending more time
designeing code instead of building it?).


>
>> 3) Does it happen often in practice that a project builds both -fPIC
>> and non-pic objects, even though only one of them is going to be
>> used?  If yes, and if it is because of a mistake on package
>> maintainer's side, can something be done about it?  (warnings, changed
>> defaults, autodetection in automake)
>>
>
> Perhaps the default should be --enable-shared --disable-static? It's worth
> considering.
>
> Peter
>
>
This is the "common subset" in action.  Some platforms can't make static
archives from PIC objects, so to make static and shared libraries, each
source file must be compiled twice.  Users can disable either one at
configure time, so Libtool is already doing everything it possibly can to
do what it should.  Changing the defaults would just cause a different
group of users to complain ;)
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool

Reply via email to