From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Old Libc, can it be tossed?
Organization: Naval Research Laboratory
Date: Tue, 5 Jan 1993 18:13:59 GMT

In article <1993Jan5.140207.29191@klaava.Helsinki.FI> kankkune@klaava.Helsinki.FI (Risto Kankkunen) writes:
>>>Can the older libc.so.4.0 & libc.so.4.1 be deleted if you have libc.so.4.2?
>>>Also, do I have to link libc.so.4.2 to libc.so.4.1 & 4.0 if I do?
>>
>>The copy of tcsh I have, which seems to be the most recent, explicitly
>>asks for libc.so.4.1.  If you make it a copy of libc.so.4.2, tcsh
>>complains that it's incompatible.  Other than tcsh, I think most
>>programs use the symlink libc.so.4, and so wouldn't care if 4.1 is
>>gone.
>
>I've had a little pause with linux and just beginning to hack with it
>again. I notice there are now shared libraries, and even in two flavors,
>I gather. Haven't seen any good explanations of how they work, though. I
>hope this hasn't been beaten to death here already or buried into the
>FAQ somewhere.

	OK, you asked for it :-).


>What's the bussiness with jump tables? I think jump tables refer to
>indirect addressing so that you can have fixed entry points to libraries
>while still be able to change the implementation. Why is there the other
>alternative, and is it still supported?

The kernel reserves the address space from 0x60000000 to 0xc0000000 for shared
libraries and each library is assigned an address ahead of time.  At the start
of each shared library is basically a series of jump instructions and these
jump off to each of the routines within libc.  When there is an upgrade to
libc, the jump instructions remain at the same address even though the actual
functions move around as required.

Before we had the jump tables, programs were linked in such a way that you
would call the function directly.  The problem with this was that you had to
relink when you went to a new version of the library.  These are called
"Classic" libraries, and are still supported and used (X11 libraries for
example).  X was too hard to jumpify and the libraries change fairly
infrequently so at the time it was decided that X remain a classic library.
The next version of the X libraries may yet be a jumptable library in some form
or another.

>What is the shared library resolution mechanism? I would think that at
>run time the the library with matching major number and highest minor
>number would be selected. Seeing people link and copy the libraries to
>different names and having had problems with programs that required 4.1,
>not 4.2, it seems this isn't the case. Why? What's the use of jump
>tables, if you cannot use old programs with newer libraries? How do I
>know, if a new library is compatible with an older one (modulo bugs)? Is
>there some internal version number in the library, or is it all in the
>name?

	Each library reference contains a couple of bits of info.  First of all
there is a filename that will be opened and is assumed to contain the library.
Secondly, the version number of the library that the program was linked to is
also stored.  At startup time, the startup code verifies that the major number
is the same, and that the minor number is >= the minor number of the library
that the program was linked to.  If there are changes in the library that would
make it impossible to have binary compatibility, then the major number should
have been incremented and the minor number should be reset to 1 (0?).  The
filename to be opened is usually in the form /lib/libc.so.4 in the case of
libc, and standard usage is that libc.so.4 be a symlink or a copy of the
version of libc that you want to use.

	If there are images out there that explicitly ask for /lib/libc.so.4.1
instead of /lib/libc.so.4, then I think that this is in error.  The image was
probably linked to some prototype version of libc before the final release.

	It turned out that there were some changes in libc 4.2 to regex which
broke sed, recompiling sed seemed to fix the problem.

-Eric
-- 
Eric Youngdale