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