[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [EXTERNAL] Re: Q: library dependencies

From: Oleg Smolsky
Subject: Re: [EXTERNAL] Re: Q: library dependencies
Date: Thu, 24 Sep 2020 13:24:26 -0700

On Thu, Sep 24, 2020 at 12:17 PM Nick Bowler <> wrote:
On 2020-09-24, Oleg Smolsky <> wrote:
> Hello, I'm working on an autotools-based build system and finally decided to
> look into these messages:
> 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:
> All these libraries are static, noinst_LILIBRARIES and the dependencies are
> expressed via _LIBADD syntax:
> libtop_la_LIBADD =
> I do this to get transitive dependencies where the top-level executable just
> needs to link to link
> I think the issue is with 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,, linking
with, since is a shorthand for directly listing all
its objects this creates a new library that contains all the objects
that made up

Now when creating the convenience library, you link against
_both_ convenience libraries and  This directly includes
all the objects of and all the objects of  But as the
objects of are duplicated in, this means some objects
are to be included twice into  Libtool has to rename one of
the objects to make this work (hence the "copying ... to avoid basename
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 to either be a dependency of OR,
but not both.

Well, both and 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]