Re: shared libs depending on static libs on x86

[Ralf Wildenhues]

Hi Jason,

* Jason Kraftcheck wrote on Thu, Mar 09, 2006 at 09:08:22PM CET:
> I've a couple questions about the behavior of libtool that I'm hoping someone
> will answer for me.  I'm using libtool 1.5.22 on Linux/x86.
> 
> 1) I have a situation as follows:  I am building both static and shared 
> versions
> of a library.  This library depends on a third-party library, which may be
> either static or shared.  If the third-party library is shared, everything 
> seems
> to work as expected.  If the third-party library is static, things work as I
> would expect when creating my static library: the third-party library is 
> listed
> as a dependency in the .la file.  However, when creating my shared library 
> with
> a static third-party library, the behavior is rather confusing.  Rather than
> just noting the third-party library as a dependency, libtool includes the text
> of the library in my dynamic library.

Yes, libtool does this on systems where deplibs_check_method=pass_all.

> Including the text of a static archive in my dynamic library makes the library
> no longer an (entirely) shared object, as it has a big chunk of non-PIC text.
> Also, this results in an unpleasant situation because the applications
> ultimately using my shared library typically also depend on other libraries 
> that
> are dependent on the same third-party library.

Yes.  libtool.m4 currently has pass_all set for too many systems.

> I understand that on some platforms (AIX?), dynamic libraries cannot have
> unresolved dependencies, making it necessary to include the static archive 
> text
> in a dynamic library on those platforms.

Oh, things are more complicated than that.  On w32 and AIX systems,
dynamic libraries cannot have unresolved dependencies.  But you can
specify dependent libraries which allow to resolve them, so there is
no need to include static archive text.  On w32 this issue is pretty
moot anyway, because there is no special PIC code.

On AIX, however, it's roughly like this: there are three different types
of linkage: static, shared, and dynamic.  The name of the archive does
not necessarily reveal the type: usually, system libraries end in '.a'
but are shared.  Usually, dynamic objects end in '.so'.  Static
libraries end in '.a' as well.  Only libraries in dynamic mode (aka
runtimelinking, enabled with '-Wl,-brtl'), can have unresolved symbols
at library creation time.

Libtool tries to model this by two different sets of behaviors,
depending upon whether -brtl was specified in LDFLAGS at configure time.

> However, it seems like the wrong thing to do when it can be avoided.

I agree.

> Why does libtool default to doing this on x86 and x86_64?

Because once there was a long dispute over this and the wrong side won
(IMHO).

> Is there some easy way I can work around this without breaking the
> build on platforms that do not allow unresolved symbols in dynamic libraries?

Yes, by changing all `deplibs_check_method' settings in the libtool
script.  I need to look up what it needs to be set to, though.

There should be a flag for easy disabling of this, for all systems that
have pass_all, unless there is really no difference in linkage.

> 2) I have a automake convenience library that is to be linked into my final
> library.  libtool generates both PIC and non-PIC versions of the objects
> contained in the convenience library.  It only uses the shared objects when
> creating the archive (.a) for the convenience library.  It then uses the 
> objects
> from the .a for the convenience library when creating both the static and 
> shared
> versions of my final library.  Why aren't the non-PIC convenience objects used
> for the static version of the final library?  Did I miss something?

This is an open TODO item.  It's a bit nontrivial to get right, but
definitely on my list of things to attack soon after 2.0 is out.

Cheers,
Ralf