On Sun, Oct 11, 2009 at 6:40 AM, Markus Meier <mae...@gentoo.org> wrote:
> > I'm trying to clean up use.local.desc a bit, so here we go: > > static-libs (used 10 times): > Build static libraries > > dbi (used 7 times): > Enable dev-db/libdbi (database-independent abstraction layer) support > In my seemingly long running request for library rationality / maximal usefulness, I would like to comment that a needed general trend is towards *all* packages (at least nearly all) that use "configure" as it is commonly distributed and install libraries in /usr/lib) should have a "static-libs" build option which determines whether or not the configure option "--enable-static" / "--disable-static" is used. Gentoo systems have ~1000 static (.a) libraries in /usr/lib which on most systems are *never* used. One could probably even get rid of the glibc static libraries unless one is building the /bin, /sbin, /etc core and admin programs in "static" mode. This is because almost all system programs use the shared libraries (in spite of the delay it will generally impose on program startup time) and the risk it imposes for fault tolerant system operations (corrupt a disk block in a shared library and you may have to re-install the entire system rather than simply rebuild a package). Needless to say these libraries under normal conditions increase the size of installs, download times for distributions and slow operations (by increasing seek times on /usr). Which is not to say that static libraries are useless. Indeed for creating program images where one wants robust regression testing across versions (e.g. browser evolution across years) or scientific programs where a static image is essential for the verification or reproduction of results the static libraries (and the building of static programs) is essential. As the current gentoo release sits, libraries/packages are almost always effectively configured as "--enable-static --enable-shared" [1]. The problem with this is that for a majority of users they do not need "--enable-static" and that for developers who would really like to build static programs (see the above paragraph) that option is currently unavailable [2] using the emerge process. So this is my vote for improving this situation over time, esp. with respect to adding "static-libs" to all of the X library ebuilds. The gradual migration of the distributed system to a "-static-libs" state is highly desirable as well. I note, because I happen to have it handy, that Ubuntu, "as installed" is almost completely in a "-static-libs" state with the exception of glibc (i.e. only 20 .a files in /usr/lib). Robert Bradbury 1. It is worth noting in my experience there is some variation across packages as to what the "default" library build option is and one doesn't know this unless one examines the configure file carefully or attempts to build the packages (usually bypassing the emerge process) all 3 ways. 2. The most glaring example being the glib and gtk+ packages where the lack of static libraries prevents the building of "static" programs, e.g. firefox, chrome, etc. which use X windows.
