From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,21e7902974a95a84,start X-Google-Attributes: gid103376,public From: Clayton Weaver Subject: Clarification: linux ext2fs, libc5, glibc Date: 1998/05/26 Message-ID: #1/1 X-Deja-AN: 356653503 Content-Type: TEXT/PLAIN; charset=US-ASCII Organization: Eskimo North (206) For-Ever Mime-Version: 1.0 Newsgroups: comp.lang.ada Originator: cgweav@eskimo.com Date: 1998-05-26T00:00:00+00:00 List-Id: 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