In message <[EMAIL PROTECTED]>, Kiran
Josyula writes:
I am new to jdk-linux.
Can anybody pls. tell me what are these libc5 and glibc libraries.
Do I require them to run java on my linux machine ?
Kiran,
I'll try to answer these questions the best I can, but we need to know
what distribution and version of Linux you're running in order to give
you specifics. I've only run Debian 1.3 and RedHat 4.2/5.0. Most of my
experience is with RedHat 5.0, and so is rather limited among the
available number of Linux distributions. While I may not be able to give
you solid answers for your exact platform, someone else here may be
able to.
I'll explain what libc and glibc are later, but first, let me say that
the current Linux JDK (1.1.5v7) tries to avoid library
incompatibilities by providing a dedicated linker/loader and "libc"
within the Linux JDK distribution itself. 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.
Finally, I'll try to address your question of, "what is libc and why
does its version matter?" I really welcome clarifications from people
who know more about the history of the Linux JDK port, UNIX, and/or
Linux. With that sense of caution, I'll proceed...
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, and superior organization of the library sources. 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.
I hope this helps, and again, I welcome clarifications and corrections
if I've made any mistakes in this post, especially because I'm a
newcomer to Linux.
Steve
