Re: [EXTERNAL] Re: Q: library dependencies

[Bob Friesenhahn]

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).  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.

> 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.

> - 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.

Since you are concerned about maintenance, then of course it is wise 
to be aware that creating a proper non-recursive build takes work. 
For me, it has been completely worth it.  GraphicsMagick is perhaps 
not the best example for how to do things since Automake has improved 
its capabilities since I made GraphicsMagick's build non-recursive.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt