Re: [EXTERNAL] Re: Q: library dependencies

[Nick Bowler]

On 2020-09-25, Oleg Smolsky <osmolsky@netskope.com> wrote:
> On Fri, Sep 25, 2020 at 6:58 AM Bob Friesenhahn 
> <bfriesen@simple.dallas.tx.us> wrote:
> > Libtool convenience libraries are not "real" static libraries.
> > Instead they are object files stored in an archive file.  Prior to
> > use (when linking using libtool) the objects are extracted and
> > passed to the linker directly (perhaps with renaming to assure
> > there are no over-writes during the extraction).
>
> Well, AFAIK any well-formed .a file (an archive) is a static lib. And these
> can be passed to the linker. Are you saying that libtool extracts the
> individual .o files instead passing -lfoo (for libfoo.a)?

Yes, this is how libtool _convenience_ libraries work (at least
conceptually: I think in some cases libtool is able to use linker
options like -Wl,--whole-archive, if supported, to achieve equivalent
results without literally unpacking the archive).

This is because _convenience_ libraries are a shorthand for linking
the individual libtool objects that comprise the library.  Linking an
archive is very different from linking the individual objects that
make up the archive.

Regular (installed) libtool libraries work differently (they are
linked like normal libraries).

[...]
> > The convenience library does not do anything regarding mutiply-defined
> > symbols (at the C language level) while linking.  If there is a
> > conflict then the linker should normally fail.
>
> I find the situation puzzling. My project has just over a hundred of these
> LT convenience libraries and there are several places where collisions
> result in renaming. Yet nowhere do I see multiply defined symbols.

I tested it a bit and it seems that when a convenience library is linked
into a _program_, libtool will just pass the static .a file directly to
the linker, without unpacking, using whole archive mode or doing anything
particularly special.  I guess this is fine because presumably portable
programs cannot tell the difference.

Because of this behaviour, duplicate objects in convenience libraries
may not be a significant problem in practice for linking programs.  With
normal linkers, individual object files that resolve undefined symbols
are effectively picked out of the archive one at a time until there are
no remaining undefined symbols that could be resolved by the library.

So once one of the duplicate objects is picked, the other is essentially
removed from consideration since it does not provide different symbols.

I'm not sure if there are any historical exceptions to this linker
behaviour that would affect portability of a package depending on this.

You will almost certainly get multiple definition errors if you tried
to link such a convenience library into a shared libtool library.

Cheers,
  Nick