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
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
