Re: Question regarding interdependent convenience libraries

[Scott D. Fleming]

> >> Is libtool or the underlying linker smart enough to recognize and
> >> ignore the duplicate libraries?
> >
> > I think that the content of convenience libraries is extracted into
> > individual .o files prior to being used for linkage.
>
> This is true if the linker doesn't have a functionality similar to
> --whole-archive, and if the resulting output is a library, rather than a
> program.
>
> > They are not used for
> > linking like traditional archive libraries.  This means that any duplicates
> > would result in individual .o files being overwritten prior to use.
>
> This is not true.  When extracted, object files with identical names are
> renamed.

I think it might be helpful to distinguish two cases:
1) Multiple *different* object files with the same name
2) Multiple occurrences of the *same* object file

Is it possible that renaming occurs in case #1 to disambiguate the
object files, but for case #2 the object files get the same name or
the duplicates are otherwise ignored?

I ask because I tried building a program using two different approaches:

1) the approach I described previously, which results in linking a
program with multiple convenience archives that contain intersecting
sets of objects, and

2) an approach in which the program is linked with convenience
archives that contain mutually disjoint sets of objects.

Neither approach produced linker errors and the resulting programs
appear to be exactly the same. It seems that either libtool or the
underlying linker somehow ignored duplicate objects found in different
convenience libraries. Unfortunately, I cannot find this behavior
documented anywhere, which makes me nervous that the behavior is
undefined and I am just getting lucky.

> > In other words non-fatal for building applications. However, if you
> > build installed libraries based on these convenience libraries, you
> > could run into trouble if two installed libraries included some of the
> > same objects.
>
> The rule of thumb is to put each convenience archive in at most one
> library, and never into a program.  (Convenience archives do not end
> up as whole in a program; if that is not a problem for you, then that
> part should be ok.)

I read this (or something similar) in the libtool documentation, and I
find the program part a bit confusing. I recall reading that a program
can also double as a library (with contained symbol table, etc.). Is
that the case where linking with a convenience archive should be
avoided? If you would please elaborate on this, I would be most
appreciative.

> > A radically-different solution is to use a non-recursive Makefile scheme.
> > This eliminates the need for convenience libraries entirely and speeds up
> > the build.  Automake does support this reasonably well and you can use
> > Makefile includes to still keep Makefile fragments alongside the sources.
> > However, the Makefile fragments require "namespacing" as if everything is
> > referenced from the top level Makefile (which they will be).
>
> This is a good suggestion.

I am familiar with the criticism of recursive make, and I'm currently
evaluating some non-recursive approaches to see if they'll work for
me. For example, this non-recursive automake template looks promising:
http://svn.ademar.org/code/trunk/autotools-build_system-template/

Thanks, Scott