On Fri, Sep 25, 2020 at 6:58 AM Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote:
> On Thu, 24 Sep 2020, Oleg Smolsky wrote: > > Libtool convenience libraries are not "real" static libraries. > Instead they are object files stored in an archive file. Prior to use > (when linking using libtool) the objects are extracted and passed to > the linker directly (perhaps with renaming to assure there are no > over-writes during the extraction). Well, AFAIK any well-formed .a file (an archive) is a static lib. And these can be passed to the linker. Are you saying that libtool extracts the individual .o files instead passing -lfoo (for libfoo.a)? > While libtool convenience > libraries are certainly "convenient" they can dramatically slow down > the build. It takes time to do the operations associated with the ar > files, but most importantly it prohibits parallelism in the build. > Yes, this is certainly a concern. I've noticed stalls in my non-recursive build. I'm guessing that is due to repackaging the libs. > > > So, I am not sure what can be done here. Could you clarify the following > > please: > > - Does the aforementioned renaming bloat the executable? > > Bloating of the executable depends on the object files linked with it. > Linkers may vary as to how smart they are at ignoring supplied objects > where no symbols have been used. > > > - How is the linker able to resolve mutiply-defined symbols for the > > duplicated nodes in the DAG? > > The convenience library does not do anything regarding mutiply-defined > symbols (at the C language level) while linking. If there is a > conflict then the linker should normally fail. > I find the situation puzzling. My project has just over a hundred of these LT convenience libraries and there are several places where collisions result in renaming. Yet nowhere do I see multiply defined symbols. If libtool/automake scripts do not do dedup... I can only guess that the linker sees .o files inside multiple .a archives (or multiple .o files coming from distinct directories via the command line) and performs dedup. Is that getting closer to the truth? > > - Is there an alternative way to express inter-lib dependencies with > > automake/libtool? > > Using a non-recursive build and using Automake macros to express what > is currently expressed as convenence libraries (using original object > files in place rather than storing in 'ar' format and extracting over > and over) will tremendously decrease build times. Automake supports > an include syntax which allows distributing build information in the > project (e.g. putting it in subdirectories next to source files) yet > incorporating in single build. If everything is ruled by one > non-recursive 'make', and the dependencies are properly cascading, > then using Automake's non-recursive build capability will provide a > huge boost to build performance, and particulary on modern multicore > systems. > > My setup is a large, non-recursive thing with "include" statements. On the top of that I am trying to understand the issues and costs imposed by the convenience libraries. My primary ask is transitive dependencies between the libs as I have more than 100 of them (and several dozen apps and hundreds of tests). Thanks in advance! Oleg.
