On Thu, Sep 24, 2020 at 12:17 PM Nick Bowler <nbow...@draconx.ca> wrote:
> On 2020-09-24, Oleg Smolsky <osmol...@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.
