Slashdot Mirror
Debian Switching From Glibc To Eglibc
ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"
Not even an old program written from Loki Software Entertainment would run on a modern Linux Mint (2.6 kernel) for example unless in a chroot'd sandbox. Truly sadistic, that I even remember this happening even on the same kernel branch. Bruce Perens would address this better than I, but my time is worth more elseware.
There should be hybridized Elf Static binary that can address this issue. Link layer is realy sucking a nut when it comes with programming, and GNU would make quite an imrpovement to have an application base that allows you to have multiple compilations in the same binary with a link-layer "tree" to how it would execute and with whether internal libraries (static) or even multiple different sets of internal libraries that are even addressable from an advanced prorgaming implementation of sentience as would a rolling book shelf archival track.
Also should be able to run a program even if a certain library is not available and not immediatly used in what function the program is performing immediaty; control the execution branch to libraries that aren't used but in certain situations, even so far is creating that library interface to return a default value so as to "satisfy" that depencancy such as a routine IsItHotOutside() to return a value int 0 without even processing anything, or able to re-direct that to another routine or function in a competing library without having it conflict with the library already used (it might be the same library but different version).
Anyhow, thanks a lot toolchains, bintools, glibc and whomever gobblers can't implement a standard without ruining the binary compatibility image that should let everthing play together.
What? That I don't have a panic attack over something being over 1 megabyte in size?