libtool
[Top][All Lists]
Advanced

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

Re: Avoid -Wl,--whole-archive


From: Tim Rühsen
Subject: Re: Avoid -Wl,--whole-archive
Date: Thu, 16 May 2019 17:28:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 5/16/19 5:00 PM, Bob Friesenhahn wrote:
> On Thu, 16 May 2019, Tim Rühsen wrote:
> 
>> Hi,
>>
>> at GNU Wget2 we are just splitting a (shared) library into several
>> smaller ones, grouped by functionality.
>>
>> We depend on gnulib and have a single libgnu.a. Each of the shared
>> libraries just need a certain set of functions from libgnu.a.
>>
>> To avoid adding everything from libgnu.a to each of the libraries, we
>> would like to avoid "-Wl,--whole-archive ../lib/.libs/libgnu.a
>> -Wl,--no-whole-archive".
> 
> There is no requirement to use "convenience" libraries.  People who do
> things due to "convenience" are often classified as "lazy". :-)

Of course I am lazy - that's why I am developer ;-) Building things to
make my life easier...

> If you have time to re-do your build structure, then I recommend using a
> non-recursive build and explicitly listing the objects which are needed
> by each library in the single Makefile.  Objects common to multiple
> libraries will then be built just once and supplied to the linker as a
> list of object files rather than fed to libtool like an "archive" file
> which is then split into object files actually supplied to the linker.
> 
> Convenience libraries are evil.  Convenience libraries slow down your
> build process dramatically and they cause 'make' not to be aware of the
> actual underlying dependencies, so that it does much more work than is
> required each type you invoke 'make'.  If you can enumerate the actual
> dependencies in the Makefile and avoid needless intermediate product
> generation, then you will achive a maximally parallel build which builds
> much faster on modern systems.

I couldn't see any speed penalty so far. Indeed, enumerating the object
files (.lo in this case) was my first approach. But we are talking about
gnulib - the number of object files is different in each environment and
also change over time. I immediately ran into issues when I pushed that
code to our CI. The exact enumeration of objects is simply not
foreseeable and thus not portable.

Your are right for projects with a deterministic number of objects...
But for projects that use gnulib *and* build more than one shared
library a '-no-whole-archive' flag would great.

> If your project is already fully built, then typing 'make' again should
> return almost immediately without doing any work at all.  If your
> project does any work at all due to typing 'make' a second time, then it
> is defective.

A second 'make' always immediately returns - if not I would change my
build recipe.

Regards, Tim

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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