linking statically against dietlibc: a blocker?

[Enrico Scholz]

seg at haxxed.com (Callum Lerwick) writes:

>> not relevant for the mentioned packages. They use only some syscalls
>> from libc and almost all logic is implemented in the programs self.
>
> If they need so little from dietlibc, why doesn't upstream just merge
> what they need into their codebase?

mmh... just a wild guess: perhaps upstream wants to use the Posix API
instead of writing assembler for zillions of different architectures
(which would be required for syscalls)?


>> Typical glibc propaganda... Numbers [1] show that some dietlibc
>> linked programs need only 10% of (non-shareable) memory than the
>> glibc counterpart.
>> 
>> glibc's dynamic loader needs more instructions and memory at startup
>> than the whole dietlibc-built program during its whole lifetime.
>
> Please explain why these packages deserve such special treatment.

freedt: beats glibc in every aspect; see
        https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582#c2
ipsvd:  recommended by upstream; DJB-suite like program
fnord:  compare the authors of fnord and dietlibc and what they think
        about glibc


> Where's the line?

It's a decision of the packager. Basically I would say, when:

1. code does not use other, non-trivial libraries
2. code is short/simple enough to be audited completely
3. code builds with dietlibc without losing features

then it is a candidate for dietlibc.

DJB-suite like programs ('daemontools' + 'ucspi*' replacements) are
usually very hot candidates for dietlibc linking.


> If dietlibc is so great, why aren't we moving the entire distribution
> over to it?

dietlibc does not fit for every program. When a program requires other
libraries, you will run into the following problems:

* most libraries are not written for static linking (e.g. do not follow
  the only-one-function-per-compilation-unit concept)
* libraries with complex algorithms are prone for security problems;
  dynamic linking makes replacing much easier

-> some libs must be linked dynamically which nullifies the benefits of
   dietlibc

Some programs depend on glibc'isms too and will not build with
dietlibc. dietlibc does not have locale(7) functionality which
makes it unsuitable for GUI programs.



Enrico