Re: [EXTERNAL] Re: Q: library dependencies

On Thu, Sep 24, 2020 at 12:17 PM Nick Bowler <[email protected]> wrote:

> On 2020-09-24, Oleg Smolsky <[email protected]> wrote:
> > Hello, I'm working on an autotools-based build system and finally
> decided to
> > look into these messages:
> >
> >   CXXLD    libtop.la
> > copying selected object files to avoid basename conflicts...
> >
> > It looks like libtool links (copies?) .o files when it finds a dupe in
> the
> > dependency DAG. Here is the situation I have w.r.t. the dependencies:
> >
> > libtop.la: liba.la, libx.la
> > liba.la: libb.la libc.la libx.la
> >
> > All these libraries are static, noinst_LILIBRARIES and the dependencies
> are
> > expressed via _LIBADD syntax:
> >
> > libtop_la_LIBADD = liba.la libx.la
> >
> > I do this to get transitive dependencies where the top-level executable
> just
> > needs to link to link libtop.la.
> >
> > I think the issue is with libx.la as it is present in two different
> branches
> > of the dependency DAG. This kind of thing is common in large projects and
> > seems strange that libtool is trying to be smart about it.
> >
> > Is there a way to tell automake/libtool to disable this copying and just
> do
> > straightforward linking? I wonder if the current behavior results in
> > unnecessary bloat?.. Or perhaps I am saved by the linker that would
> dedup?
>
> Unless I misunderstand something, what you describe is the documented
> and expected behaviour.
>
> When using primaries such as noinst_LTLIBRARIES, Automake will generate
> rules that create libtool convenience libraries.  Such libraries are
> basically intended to be a convenient shorthand for directly listing
> the libtool objects that make up the convenience library whenever you
> use libtool to link with it.
>
> So when you create another libtool convenience library, liba.la, linking
> with libx.la, since libx.la is a shorthand for directly listing all
> its objects this creates a new library that contains all the objects
> that made up libx.la.
>
> Now when creating the libtop.la convenience library, you link against
> _both_ convenience libraries liba.la and libx.la.  This directly includes
> all the objects of liba.la and all the objects of libx.la.  But as the
> objects of libx.la are duplicated in liba.la, this means some objects
> are to be included twice into libtop.la.  Libtool has to rename one of
> the objects to make this work (hence the "copying ... to avoid basename
> conflicts").
>
Right, that's the behavior I am seeing. Thank you for confirming!


>
> I assume this is not the desired result.  Probably simplest to just
> arrange for libx.la to either be a dependency of libtop.la OR liba.la,
> but not both.
>
> Well, both libtop.la and liba.la use the lower-level lib and I want to
support all users (as I have many paths through the dependency DAG). I
provided a reduced/simplified example as it is representative of my
codebase - the dependencies have many collisions, sometimes with more steps
in between (but no cycles).

The thing here is that there are many libraries and I've expressed the
dependencies with via  _LIBADD. I would like to claim that these are both
(syntactically) correct and (logically) sound. These dependencies serve a
useful purpose: any user can link to any library and will then get the
whole list of transitive dependencies. This is a boon when the DAG is large
and complex. (IIRC CMake works it out correctly)

So, I am not sure what can be done here. Could you clarify the following
please:
- Does the aforementioned renaming bloat the executable?
- How is the linker able to resolve mutiply-defined symbols for the
duplicated nodes in the DAG?
- Is there an alternative way to express inter-lib dependencies with
automake/libtool?

Just to make it clear, I understand that my current dependency DAG can be
turned into a tree for some cases. I could also eliminate the dependencies
altogether and force it upon the programs to express the whole dependency
set. The problem with that is dependency leakage - an addition to a
lower-level lib negatively effects every single direct and indirect user.
Really uncool in terms of maintenance.

Thanks!
Oleg.