From: Eric Youngdale (eric@tantalus.nrl.navy.mil)
Date: 02/27/93


From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Unsharable Shared Libraries.
Date: Sat, 27 Feb 1993 20:12:07 GMT

In article <1mmrkiINN2g2@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>
>In article <1993Feb26.164100.23994@sun0.urz.uni-heidelberg.de>
>geyer@kalliope.iwr.uni-heidelberg.de (Helmut Geyer) writes:
>>
>> When a completely changed library (i. e. not only a new version, but
>> a new release) is installed no binaries using the old shared
>> libraries will work with the new ones in SunOS either.
>
>That depends on *exactly* what changes. Under SunOS (and AIX 3),
>shared libraries are dynamically linked, so the *only* thing which
>would require relinking is a change to a functional interface or global
>variable. Both would also require recompiling some code.
>
>Linux shared libraries are far inferior; trying to deny that is absurd.

        The linux shared libraries have some points that make them better than
a Sun or SVr4 type of shared libraries, and there are some points which make
them weaker. To say that they are far inferior overstates the case a bit,
although prior to the DLL in libc.4.3 and libX.3.0 I might have agreed with
you. Most people are aware that libc.4.3 is binary compatible with libc.4.2
and libc.4.1, and there is no reason why the next libc and the versions that
come after that will ever need to break old binaries. Similarily, the next X
release will be binary compatible with libX*.3.0, so there will be no need to
recompile applications when a new X release comes out.

        As an example of where the linux shared libraries are better than
shared libraries under Sun or SVr4, consider that the dynamic linking under
SVr4 requires that a special symbol table be present that lists each symbol
that needs to be resolved by the various shared libraries, and this obviously
increases the size of the binaries. There is also a startup overhead as the
libraries are searched for the required symbols, since you effectively have to
do a linking of the program each time you run it.

        Under linux, the dynamic linking tables are built by the linker. This
means that each binary does not need to have a list of symbols that need to be
resolved, and that at run time the startup code simply walks through a table
and copies pointers around to achieve the dynamic linking. The only time
pointers are added to the table is when there are multiple versions of the same
symbol around (i.e. one in your program and another in the shared library), so
for most programs the additional overhead for would be on the order of 30
bytes. Fast and lightweight.

-Eric

--