linking statically against dietlibc: a blocker?

[Peter Gordon]

Patrice Dumas wrote:
> Other contributors disagree with this choice, but I think that the
> situation should be clarified once for all, and it should said
> whether this is a blocker or not.

I'm of the opinion that statically linking against *ANYTHING* [1] means that the package in question
is flawed by design.

Firstly, shared libraries mean that only that specific library needs to be rebuild for any updates.
This makes it much more difficult to keep up with security and major bugfix issues, as one would be
required to rebuild *EVERY* package that links statically to that library.

Secondly, static libraries (as I understand their workings) are stored in memory with the binary
image of the program that is running. This leads to (theoretically) multiple copies of that library
wasting memory space needlessly. On the other hand, shared libraries also keep multiple copies of
the library code in memory, but the kernel handles that effectively by storing only one actual copy
and using things like Copy-On-Write and virtual memory addressing to make it appear to userspace
that a copy exists per each program.

Thirdly, you brought up the point that "there is a gain in term of efficiency (and potentially
portability)." The way I see it: Linking statically for these purposes is nothing but a hackish
workaround. If glibc or another system library needs fixing for speed or portability issues, then it
should be fixed, not bypassed. This would result in virtually *every* application having better
speed and increased portability. That is the Right Way(TM), I believe.

Yes, it will take longer and the program will run slower until that happens, but doing things the
right way over a long period of time is better than hacks for short-term gains.

[1] Unless absolutely needed, as in the case of rescue binaries and such where one or more specific
shared libraries that are needed are not guaranteed to be functional, much less even assured to be
present on the system...
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
My Blog: http://thecodergeek.com/blog/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061003/eb7fab5e/attachment.sig>