On 2020-09-24, Oleg Smolsky <osmolsky@netskope.com> 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.