Clarification: linux ext2fs, libc5, glibc

Clarification: linux ext2fs, libc5, glibc

[Clayton Weaver]

For those who don't follow linux development closely, the current
confusion between libc5 and glibc is a matter of (mostly) abstract
data type #defines and typedefs in header files. libc5 and earlier
used kernel headers that specified the type of data types of the
"typename_t" variety. This simplified type compatibility when a
libc functions was just a wrapper around a linux system call, but
introduced kernel version dependencies in user application code
ported to linux libc.

When the kernel headers changed in the kernel development process,
the libc5 headers would have to be changed, and that would break
user application code until it was updated for the libc5 changes.

With glibc, they're moving away from the separate linux libc tree, and
glibc is replacing what used to be defined in kernel headers in
/usr/include/linux and /usr/include/asm (symlinks into the kernel source
tree) with it's own header files specifying those data types. This allows
the kernel to use and change at will whatever data type bit widths are
most convenient for internal kernel and device driver development without
requiring changes to the libc code for those data types that don't have
to be supplied to a kernel system call, thus not randomly breaking linux
ports of user application software with every modification to the kernel
system calls.

However, the glibc developers are looking ahead to larger address spaces
and other issues that require wider data types than linux has needed in
the past, so some of the abstract data types defined in the glibc headers
are not the same as the typedefs the kernel headers in linux 2.0.x used.

This often breaks code that works fine with libc5 when it's recompiled
with glibc, if it even compiles at all without changes to the source.

For ext2fs, which is used on both libc5 and glibc systems, the developers
are of course aware of this, but patches for glibc changes that affect
ext2fs still show up at least as recently as two months ago.

In re: my earlier comments, ext2fs 1.0.6 works fine with libc5 (gcc
2.7.2.1, libc5.4.7 up to 5.4.44, -O -m486 -fno-strength-reduce has
produced ext2fs 1.06 code that has been stable for 2 years on my system). 
Newer versions (ext2fs 1.10 and up) I haven't used myself, but those have
had patches to accomodate glibc changes applied to the ext2fs source tree,
so whatever ships with a native glibc linux system is probably the right
version to use (with Redhat 5.x, for example). I didn't mean to suggest
downgrading a glibc linux system to ext2fs 1.06. 

Some filesystem changes are planned for the near future (a btree of 
file extents in the metadata, for example, is one development path that
the ext2fs developers are considering), but as of now and probably up
through linux 2.2 releases, the standard ext2fs versions used with both
libc5 and glibc linux systems use the same filesystem format.

This allows one to dual boot two different linux systems on the same box
and share partitions, even if the ext2fs versions are different. You don't
want to share a directory like /usr/include or /usr/lib, where the
differences between libc5 and glibc are found directly, and you probably
don't want to share any of the ../bin directories, but sharing data
directories that don't hold compiler-relevant and binary code is just a
matter of setting the /etc/fstab entries to mount those partitions
wherever you want them at bootup on either system.

The swap partition format also hasn't changed, so you can share swap
partitions between quite different linux distributions, with different
kernel and standard C library versions and mounted from different
root partitions, on the same system.

And any files from the "other" system that you need temporary access to
you can always get by manually mounting that partition on /mnt and
retrieving the files, rather than rebooting (to look up some saved
mail or news message in your "other" home directory, for example).

It's my view that this should considerably reduce the confusion resulting
from having to keep multiple versions of gcc, libc, and /usr/include
around and make sure the symlinks all point at the right place for any
given compile.

Regards, Clayton Weaver  cgweav@eskimo.com  (Seattle)

-- 

Regards, Clayton Weaver  cgweav@eskimo.com  (Seattle)

"Since this is a technical newsgroup and has mostly done a pretty good job