[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
signature.asc
Description: OpenPGP digital signature