Hadron wrote:
> Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> writes:
>
>> EGLIBC: Not a fork, but a glibc distribution
>>
>> ,----[ Quote ]
>> | The GNU C library (or glibc) is a fundamental component of the Linux
>> | operating system. It provides much of the user-space interface to the
>> | kernel as well as a sizable portion of the utility routines that are
>> | used by virtually all Linux applications. A variant of glibc known as
>> | Embedded glibc or EGLIBC is not very well known outside of the embedded
>> | space, but that looks to be changing with the announcement that Debian
>> | will switch from glibc to EGLIBC.
>> `----
>>
>> http://lwn.net/Articles/333755/
>>
>>
>> Recent:
>>
>> Debian changes from GLIBC to EGLIBC
>>
>> ,----[ Quote ]
>> | With a short message on his blog, Debian developer and maintainer
>> | Auréllian Jarno has announced a fundamental change in future Debian
>> | releases. The EGLIBC (Embedded GNU C Library), originally developed for
>> | embedded systems, is to replace GLIBC (GNU C Library).
>> `----
>>
>> http://www.h-online.com/open/Debian-changes-from-GLIBC-to-
EGLIBC--/news/113228
>>
>
> FFS. What a disaster. Queue Debian/non specific bugs left right and
> centre.
I agree. With something as fundamental as the libc I think this is a step
backwards. Even by fixing bugs they may break compatibility in some areas.
I have written several little languages, and compilers that use direct
syscalls via generated machine code (for Linux, and BSD). BSD tends to use
the SysV i386 ABI for syscalls, which primarily uses the stack for passing
data to a syscall. Linux uses a different ABI. With the Linux x86 ABI some
of the syscall args are passed via registers. The problem with the Linux
design, is that it favors a C-based approach, and has made the porting of
some compilers to Linux more difficult. The Linux kernel headers in fact
use gcc-specific features with C macros to make gcc store arguments in the
registers. So, that's good for C code perhaps, but when you consider that a
language other than C often has to spill those registers, and save them some
place, before the call, so that they may be restored afterwards, it tends to
hurt the performance of other languages. In more recent times I have
produced some C code that interfaces, with the machine code my compiler
generates, so there is more indirection. My concern is that the C code will
need to be rebuilt for every distribution, and it's probably warranted, with
or without the glibc change.
As it is now, if you compile a program or library with a version of glibc
that is newer than the library that your users use, even if you don't use
any of the features that might be found in a delta of the new and old, it
won't work. A lot of software is thus built with old versions of Linux,
because this allows for more forward compatibility, but unfortunately it
doesn't eliminate the problems with some code changes.
I'm using an old static version of Skype, because the Ubuntu (shared
library) package no longer works correctly (it segfaults), in Ubuntu 9.04.
Something has changed in the ABI, or some address space change (perhaps due
to unrelated code changes), has resulted in the packaged version no longer
working.
-George
|
|
