From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-38031-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1MwxHA-0004MU-1N
for garchives@archives.gentoo.org; Sun, 11 Oct 2009 12:11:48 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 71720E05E8;
Sun, 11 Oct 2009 12:11:46 +0000 (UTC)
Received: from mail-fx0-f220.google.com (mail-fx0-f220.google.com [209.85.220.220])
by pigeon.gentoo.org (Postfix) with ESMTP id 0B30AE05E8
for <gentoo-dev@lists.gentoo.org>; Sun, 11 Oct 2009 12:11:45 +0000 (UTC)
Received: by fxm20 with SMTP id 20so7745866fxm.14
for <gentoo-dev@lists.gentoo.org>; Sun, 11 Oct 2009 05:11:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type;
bh=lnZkTLJ+FI+ILNWGvUW1iEdXDjmtEJeAeaGZsh39nUQ=;
b=u/WOFqjvE31TFbMX0bjuOCCU3oh20AZcsstU6ydLDQWy6SrD5ucX+zu7rGoappsLQ9
v0R9/JLCwHkQspHv7FI7N3gyzR3Uudlu1hLQCdPZcDqKXE3KOw5AGppCWRkGvG7nLnNj
2Jq7ZEdK9a4W/FSW9BCqCnX8d5Z4J8AoXCOEY=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=UUF4kivOVsiUmHCcTPFvmnNrgnVn6NU4/SlOGZUrlgv0Goh1XaIKKDUTTxAjzjFw4N
h7cb7mWSL/jw8JCX7CbcVwKLK2raOchrCcF9ECTUlNkEIhAqTOakVJWfKjEFW6Wq1kBC
aS6XxFdLR7hFGfe+Vozu4mJfXJ7IlZOvQo0xU=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.86.235.14 with SMTP id i14mr4275330fgh.52.1255263105415; Sun,
11 Oct 2009 05:11:45 -0700 (PDT)
In-Reply-To: <20091011124035.768d24fa@gentoo.org>
References: <20091011124035.768d24fa@gentoo.org>
Date: Sun, 11 Oct 2009 08:11:45 -0400
Message-ID: <deaa866a0910110511x354e589fw9b1f8a6ce83fa6d3@mail.gmail.com>
Subject: Re: [gentoo-dev] [RFC] new global useflags: static-libs and dbi
From: Robert Bradbury <robert.bradbury@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: multipart/alternative; boundary=001485e6fe3c7f7be60475a7b7d5
X-Archives-Salt: 05ca4539-bc8a-4a98-9f76-fa1b10ebaf35
X-Archives-Hash: f5815a24be78c9cfc1e1b2fa5d390537
--001485e6fe3c7f7be60475a7b7d5
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Oct 11, 2009 at 6:40 AM, Markus Meier <maekke@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.
--001485e6fe3c7f7be60475a7b7d5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">On Sun, Oct 11, 2009 at 6:40 AM, Markus Meie=
r <span dir=3D"ltr"><<a href=3D"mailto:maekke@gentoo.org">maekke@gentoo.=
org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I'm trying to clean up use.local.desc a bit, so here we go:<br>
<br>
static-libs (used 10 times):<br>
Build static libraries<br>
<br>
dbi (used 7 times):<br>
Enable dev-db/libdbi (database-independent abstraction layer) support<br>
</blockquote></div><div><br></div><div>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) tha=
t use "configure" as it is commonly distributed and install libra=
ries in /usr/lib) =A0should have a "static-libs" build option whi=
ch determines whether or not the configure option "--enable-static&quo=
t; / "--disable-static" is used.<br>
</div><div><br></div><div>Gentoo systems have ~1000 static (.a) libraries i=
n /usr/lib which on most systems are *never* used. =A0One could probably ev=
en get rid of the glibc static libraries unless one is building the /bin, /=
sbin, /etc core and admin programs in "static" mode. =A0This is b=
ecause 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 im=
poses for fault tolerant system operations (corrupt a disk block in a share=
d library and you may have to re-install the entire system rather than simp=
ly rebuild a package). =A0Needless to say these libraries under normal cond=
itions increase the size of installs, download times for distributions and =
slow operations (by increasing seek times on /usr).</div>
<div><br></div><div>Which is not to say that static libraries are useless. =
=A0Indeed for creating program images where one wants robust regression tes=
ting across versions (e.g. browser evolution across years) or scientific pr=
ograms where a static image is essential for the verification or reproducti=
on of results the static libraries (and the building of static programs) is=
essential.</div>
<div><br></div><div>As the current gentoo release sits, libraries/packages =
are almost always effectively configured as "--enable-static --enable-=
shared" [1]. =A0The problem with this is that for a majority of users =
they do not need "--enable-static" and that for developers who wo=
uld really like to build static programs (see the above paragraph) that opt=
ion is currently unavailable [2] using the emerge process.</div>
<div><br></div><div>So this is my vote for improving this situation over ti=
me, esp. with respect to adding "static-libs" to all of the X lib=
rary ebuilds. =A0The gradual migration of the distributed system to a "=
;-static-libs" state is highly desirable as well.</div>
<div><br></div><div>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).</d=
iv>
<div><br></div><div>Robert Bradbury</div><div><br></div><div>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 t=
his unless one examines the configure file carefully or attempts to build t=
he packages (usually bypassing the emerge process) all 3 ways.</div>
<div>2. The most glaring example being the glib and gtk+ packages where the=
lack of static libraries prevents the building of "static" progr=
ams, e.g. firefox, chrome, etc. which use X windows.</div>
--001485e6fe3c7f7be60475a7b7d5--