java-linux@java.blackdown.org FAQ: General Questions about Linux

8. General Questions about Linux

This FAQ tries to focus on the Blackdown JDK, but we attempt to answer a few Linux-specific questions here.

8.1 Last Update

$Id: 08-linux.sgml,v 1.1 1998/11/13 02:50:16 stevemw Exp $

8.2 Where Can I Find Linux FAQs, Mailing Lists, and Documentation?

Here's a list of good places to start:

The Linuxdoc project: http://sunsite.unc.edu/LDP/.
The main Linux website: http://www.linux.org/.
Linux kernels and libraries: http://www.kernel.org/.

8.3 What is glibc, and Why Does it Matter?

I'll explain what libc and glibc are in a bit, but first, let me say that the current Blackdown Linux JDK tries to avoid library incompatibilities by providing a dedicated dynamic loader and its own libc.so. And (I think) even before this change, the problem of "which of libc5 or glibc is needed" was theoretically only experienced on systems such as RedHat 5.0 and Debian 2.0 that had so rapidly moved to glibc. Other library conflicts are always bound to happen because of the variety of Linux versions and configurations there are.

The UNIX "libc" is the core set of functions to which most utility and application code links. You can see references to libc in the intro(3) manual page. For your information, functions described in section two (see intro(2)) of the manual are all inside the kernel, whereas section three describes those which may be standard, but are stored in separate libraries. To view these pages, make sure your core manual pages are installed, and type man 3 intro, for example.

In order to save disk space and memory, modern operating systems like Linux have taken to using "shared" libraries that don't move their contents into code which links to them during the build process. Although there is a /usr/lib/libc.a, most production code is linked to /usr/lib/libc.so, which is typically a link-editor script for selecting the actual libc.so (shared object) archive.

In short, lots of programs on your system share code out of one or more files as they execute. To see what shared code an executable needs, there is an optional Linux utility named ldd(1). If it's on your system, you can type ldd PROGRAM to see its shared libraries.

Here's an example:

$ ldd /bin/ls
        libc.so.6 => /lib/libc.so.6 (0x40003000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

The older (and still most common) Linux libc was known as "libc5." The GNU/Linux development community sought to improve on it by adding thread-safety where possible, 64-bit support, better POSIX and XPG4.2 compliance, superior organization of the library sources, and multi-byte character locale support. These and other changes will bring even more robustness and quality to the Linux development environment. Although the changes are inconvenient to us sometimes, the end result should be worth it.

The new library is now called "glibc" because it's a library common across Linux and HURD, and enjoys a broad base of GNU developer contributions. (I don't know how much of the earlier Linux libc software was derived from GNU libc, which has been around for quite a while on its own, I think.)

For more information on GNU libc, see http://www.imaxx.net/~thrytis/glibc/. Since C is central to the history and development of UNIX and Linux, you might enjoy the links found on http://www.dundee.ac.uk/~bmsimpso/work/C-Programming/ as well.