NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/unix/bsd/10191

Internet Message Format | 1992-12-14 | 5.1 KB

Path: sparky!uunet!enterpoop.mit.edu!snorkelwacker.mit.edu!ai-lab!hal.gnu.ai.mit.edu!ericy
From: [e-mail] (Eric Youngdale)
Newsgroups: comp.unix.bsd
Subject: Re: Shared lib benchmarks, and experiences
Date: 14 Dec 1992 17:02:37 GMT
Organization: /etc/organization
Lines: 80
Distribution: usa
Message-ID: <[e-mail]>
References: <veit.724064215@du9ds3> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: hal.gnu.ai.mit.edu

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>,
>[e-mail] (Eric Youngdale) writes:
>
>| Perhaps you do not understand.  The way our linux libraries are made, you can
>| just drop a new version into the /lib directory, and add a symlink, and you are
>| ready to run the same binaries with the new sharable library. There is no need
>| to relink[...]
>
>According to private correspondence, I'm told you can even do this without
>the symlink by using environment variables.
>
>But, there are severe restrictions:
>
>  1) The two librarys must have identical ``assigned'' addresses, and
>  2) The two librarys must be substantially identical.

    The first point is correct.  I should point out that there is no reason
why we cannot have two different libraries assigned to the same address - you
just will not be able to use both at the same time in the same process.  The
way that it works is that there is something very analagous to a global
constructor in C++, which looks for certain "special" variables.  These
variables contain the name of the sharable library, the assigned address, and
the version number.  When crt0 sees these variables, the requested libraries
are mapped into the address space of the process.

The second one depends upon how you define "substantially".

>By #2 I mean that if the second library is, say, built from a completely
>different set of object files, and a completely different set of ``internal''
>routines, and is of a substantially different size, it won't work (even though
>the ``interface'' is the same).  This is why I raised the example of
>Xaw3d -vs- Xaw.  On SVR4 each process can elect to use one or the other of
>these libraries with the same binarys (say xterm) at the same time.  I
>still don't think this is the case with linux, but correct me if I am wrong.

    The example that you provide of Xaw/Xaw3d is not one that I am terribly
familiar with.  As a rule of thumb, as long as you can provide identical
assigned addresses, you can generate plug compatible libraries.  The
limitations have less to do with the design of the library itself, but have
more to do with the tools that we have available to ensure that the various
addresses remain the same from one version to the next.

    The tricky bit in the past had been how you assign identical addresses
to global data, and up until recently we had simply placed all global data in a
separate file.  This worked fine for libc, but did not work for the X libraries
(so I am told) because it would have meant modifying the X source code heavily.
Thus the libraries had to be nearly identical so that individual data items did
not get moved around in memory, and what you were told in private
correspondence is essentially correct for things as they stand now with the
publicly available libraries that we have.

    I recently came up with a way of "extracting" the global variable
declarations from the main files and shunting them off to separate files, so we
now have complete freedom to arrange the global data any way we wish (as long
as two variables do not overlap).  All of this is handled at the assembly code
level, so there are no source code modifications to the library required.  If
we assume that Xaw and Xaw3d have a common interface for the Xaw part, then
there is no reason in principle why one cannot have sharable libraries for the
two cases that have an identical interface.

    I want to add in passing that there were a lot of people who wanted
some kind of dynamic linking instead of what we ended up with.  Clearly there
are pros and cons to either approach, and we had to balance these to come up
with an answer.  As I recall the biggest drawbacks to the dynamic linking were
the need for a new assembler and linker, the need for more extensive kernel
mods, larger binaries and more overhead to load a program.  In its favor
was the greater likelyhood that old binaries would still run with a new
library, and no need for assigning addresses ahead of time.

    Finally some people are wondering why we are discussing the linux
shared libraries on the comp.unix.bsd list.  The original question had to do
with shared experiences, and some people naturally were wondering how we do
this under linux.  This is somewhat of a moving target, although most of this
is not visible to the regular user.  Since I have been close to some of the
discussions relating to the development I wanted to give my perspective and let
you know where we currently are.  You will ultimately decide one thing or
another, and the only thing that I can guarantee is that some people will not
be happy.  In our experience, the malcontents will eventually forget about it.