[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 11:28:18 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Fri, 25 Sep 2020, Oleg Smolsky wrote:

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

Exactly! It might as well be a tar file except that the 'ar' archiver knows how to add/update/remove files from it and that is not possible with a tar file. The ability to do incremental updates of the archive file is important as objects are built/rebuilt. The 'make' program itself already understands archive files.

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.

Probably the "renaming" is the naming of the extracted object files. The object/library symbols can not be renamed.

Over a hundred convenience libraries sounds like quite a lot!

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?

When it extracts the files the file names can not collide. Automake can help with this by producing unique naming.

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

With convenience libraries, there may be a necessary build order but the object files are not 'linked' before going into the convenience libraries (as a proper library would be) so all linking is when the final library or program is linked using the objects from the convenience libraries.

Using convenience libraries does provide the benefit of avoiding the "deadly embrace" which might be encountered when using shared libraries with cross-dependencies.

Bob Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

reply via email to

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