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