From: tfoley@camaro.uucp (Tim Foley)
Subject: Old Libc, can it be tossed?
Date: 3 Jan 93 13:15:43 GMT
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?
Where's Hennus Bergman? Anyone know?
--
--------------------------------------------------------------------------
The HeartBeat of America...Yesterdays Camaro Z28
tfoley@camaro.uucp
Call the Camaro Linux Pub-access site: 1-416-238-6550 USRobotics HST
Note: Please, no ftpmail or mailing lists or the host gets annoyed :)
--------------------------------------------------------------------------
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Subject: Re: Old Libc, can it be tossed?
Date: 4 Jan 93 05:08:56 GMT
tfoley@camaro.uucp (Tim Foley) 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.
From: kankkune@klaava.Helsinki.FI (Risto Kankkunen)
Subject: Re: Old Libc, can it be tossed?
Date: 5 Jan 93 14:02:07 GMT
>>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.
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?
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?
I would have looked up answers to some of these questions from the
sources hadn't I accidentally formatted part of my hard disk the other
night and being now busy recovering what's still left there...
--
me olemme maailma tiet{v{tk| ne ett{ on jouluaika ollenkaan
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Old Libc, can it be tossed?
Date: 5 Jan 93 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
From: ss@uucp
Subject: Re: Old Libc, can it be tossed?
Date: Tue, 5 Jan 1993 20:08:35 GMT
In article <C0E7zB.8xL@ra.nrl.navy.mil>
eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:
[very informative background about jump/shared libs]
My only complaint about linux jump/classic shared libraries is the
difficulty with which the're created, especially the X libs. Right now
it seems only a handful of people can actually put together
jump/classic shared libs. I can think of many widget sets that I'd
love to use but have to forego since I only how to make them static
(Wcl, Xc, and Xaw3d come to mind). Are we to expect a collection of
scripts that would automate or semi-automate the process of making
shared libraries and render making them feasible to the average user?
I hope so. Right now I know only of ones in the GCC directory on
tsx-11 which are overly difficult and seem very specific to only the
libs they were written for.
/Muhammad M. Saggaf | Stop the genocide
alsaggaf@athena.mit.edu | Save Bosnia
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Old Libc, can it be tossed?
Date: Tue, 5 Jan 1993 22:48:10 GMT
In article <1993Jan5.200835.16902@athena.mit.edu> ss@uucp writes:
>In article <C0E7zB.8xL@ra.nrl.navy.mil>
eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:
>
>[very informative background about jump/shared libs]
>
>My only complaint about linux jump/classic shared libraries is the
>difficulty with which the're created, especially the X libs. Right now
>it seems only a handful of people can actually put together
>jump/classic shared libs. I can think of many widget sets that I'd
>love to use but have to forego since I only how to make them static
>(Wcl, Xc, and Xaw3d come to mind). Are we to expect a collection of
>scripts that would automate or semi-automate the process of making
>shared libraries and render making them feasible to the average user?
>I hope so. Right now I know only of ones in the GCC directory on
>tsx-11 which are overly difficult and seem very specific to only the
>libs they were written for.
You should join the GCC channel :-). Seriously, over the past month or
so, a new set of tools has been developed which makes the sharable jump-table
library generation pretty foolproof. You just need to set up a few things in
your Makefile, make the library, and then run two different programs - one to
generate the stub library and a second one to generate the image library
itself. In general, you should never have to modify the source code for the
library. These tools have not been publicly released (I think that they have
been announced on the GCC channel, but not on c.o.l) yet because they are still
under development. I will say that I was able to generate a jumpified version
of the bfd library from gdb-4.6, and then generate a compatible upgrade from
the bfd in gdb-4.7, and all of this with only a minimum amount of effort. The
upshot is that I believe it now possible to generate jumptable X libraries,
because these tools can handle global data in ways that the old tools could
not. I would also add that nearly all of the old tools were discared as they
were too complicated (i.e. I could not figure out how to use them :-). The
jumpified X libraries have not yet been generated because there is no pressing
need for new X libraries at the moment, and there are other technical problems
that need to be addressed.
Consideration is being given to some form of dynamic linking. It turns
out that there are many situations that we simply cannot handle properly (some
of which are specified by posix), and the only way to do it correctly is with
some kind of dynamic linking (much of the effort involved in jumpifying the bfd
library was dealing with an issue that would be handled correctly by dynamic
linking). The lack of this capability has lead to a number of difficult to
find bugs, and there seems to be general agreement on the GCC channel that some
kind of dynamic linking will be in your future. The only disagreement has
generally been with implementation issues (i.e. PIC/non-PIC, binary bloat,
impact on page sharing and demand loading, etc). I wrote a prototype version
of dynamic linking (which actually works, btw) over the long weekend and it is
possible that this or some other scheme will eventually be used when building
sharable libraries. There are compiler issues that need to be resolved before
my prototype is usable for a large scale library (i.e. libc, X11).
The dynamic linking prototype can be tested by people - I put it up for
anonymous ftp on Sunday and announced it to the GCC channel, but someone has
already pointed out a fairly subtle issue that needs to be addressed. If
anyone wants to try this out, drop me an email message. It does work for Rich
Salz's editlib which I have been using as a guinea pig while doing tool
development. The tools for generating a non-dynamicly linked library could be
released separately, but they are undergoing quite a bit of change as they are
also used with the dynamicly linked libraries. I do not recommend that people
try the dynamic linking if they are hot to build some library because a lot of
it is subject to change.
-Eric
--
Eric Youngdale