[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [EXTERNAL] Re: Q: library dependencies

From: Bob Friesenhahn
Subject: Re: [EXTERNAL] Re: Q: library dependencies
Date: Fri, 25 Sep 2020 08:58:20 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

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

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 Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]