linking statically against dietlibc: a blocker?

[Ralf Corsepius]

On Wed, 2006-10-04 at 02:14 -0500, Callum Lerwick wrote:
> On Wed, 2006-10-04 at 08:42 +0200, Enrico Scholz wrote:
> > 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?

Both approaches mean circumventing libc by replacing libc functions with
private versions.

Whether "statically linking against dietlibc" or including private
copies doesn't make any real difference. It's essentially the same.
Both suffer from the same flaws and problems.

> > 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.
> Where's the line? If dietlibc is so great, why aren't we moving the
> entire distribution over to it?

... because responsible maintainers care more about intetrating
applications into the OS, but circumventing it and by "pimping
applications"? Carefully designed applications *use* the OS (of which
libc is an essential part of) and "just live with a
compromises/trade-offs".

Ralf