From: julien@incal.inria.fr (Julien Maisonneuve)
Subject: Unsharable Shared Libraries.
Date: 26 Feb 93 11:00:21 GMT
library with a different version number than the one the application was compiled
with.
This is a problem because in practise, you always have executables compiled with
different versions on your disk. So you have to keep libraries of every version
for wich you have an executable, and since libraries are large objects and that
there are many of them, it takes up too much disk space.
Moreover, if you get a shrink-wrapped executable for which you do not have the
right library version (even though you have the latest libraries), you can as
well throw it away.
The SunOS approach is much better: whenever a new shared library is installed
(with ldconfig), whatever its version is, it is seen as the regular library for
all executables. You only need to keep one library of each kind around,
installing the most recent library ALWAYS works.
So, unless I was totally wrong from the start, I would like to know if there is a
way to make Linux behave a bit like SunOS, and why it was not designed that way
in the first place.
Thanks,
--
_________ Julien.Maisonneuve@inria.fr julien@sor.inria.fr
/ _ _ _ ...!uunet!inria!corto!julien
/ /) ' ) ) ) INRIA : 33 (1) 39 63 52 08
__/_ // o _ __ / / / _ o _ _ __ __ _ _ _
/ / (_(_(/_(_(<_/) ) / ' (_(_(_(_/_)_(_)_/) )_/) )_(<_(_(_( \_)-(<_
(_/
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Unsharable Shared Libraries.
Date: Fri, 26 Feb 1993 15:57:39 GMT
In article <5083@seti.inria.fr> julien@incal.inria.fr (Julien Maisonneuve) writes:
>This is a problem because in practise, you always have executables compiled with
>different versions on your disk. So you have to keep libraries of every version
>for wich you have an executable, and since libraries are large objects and that
>there are many of them, it takes up too much disk space.
>Moreover, if you get a shrink-wrapped executable for which you do not have the
>right library version (even though you have the latest libraries), you can as
>well throw it away.
You misunderstand how linux works. An executable that is linked to
libc.4.1, libc.4.2 or libc.4.3 will all work with libc.so.4.3 - there is no
need to keep old versions of libc around to run old executables (Note that
a program linked to 4.3 will not run with 4.1).
The old X libraries were not set up in this way, so you did have to
keep old versions of the library around, but with the new DLL libraries it will
be possible to slip in new sharable libraries and delete the old ones when a
new X is released.
-Eric
From: geyer@kalliope.iwr.uni-heidelberg.de (Helmut Geyer)
Subject: Re: Unsharable Shared Libraries.
Date: Fri, 26 Feb 93 16:41:00 GMT
In article <5083@seti.inria.fr>, julien@incal.inria.fr (Julien Maisonneuve) writes:
|>
|> library with a different version number than the one the application was compiled
|> with.
|>
|> This is a problem because in practise, you always have executables compiled with
|> different versions on your disk. So you have to keep libraries of every version
|> for wich you have an executable, and since libraries are large objects and that
|> there are many of them, it takes up too much disk space.
|> Moreover, if you get a shrink-wrapped executable for which you do not have the
|> right library version (even though you have the latest libraries), you can as
|> well throw it away.
|>
|> The SunOS approach is much better: whenever a new shared library is installed
|> (with ldconfig), whatever its version is, it is seen as the regular library for
|> all executables. You only need to keep one library of each kind around,
|> installing the most recent library ALWAYS works.
|>
|> So, unless I was totally wrong from the start, I would like to know if there is a
|> way to make Linux behave a bit like SunOS, and why it was not designed that way
|> in the first place.
|> Thanks,
|>
|> --
|> _________ Julien.Maisonneuve@inria.fr julien@sor.inria.fr
|> / _ _ _ ...!uunet!inria!corto!julien
|> / /) ' ) ) ) INRIA : 33 (1) 39 63 52 08
|> __/_ // o _ __ / / / _ o _ _ __ __ _ _ _
|> / / (_(_(/_(_(<_/) ) / ' (_(_(_(_/_)_(_)_/) )_/) )_(<_(_(_( \_)-(<_
|> (_/
As I understand it, the Linux shared libraries do just the same. Whenever a new version of a
shared library is installed, all binaries will use this (and usually there are no problems
concerning this - a hooray for all library maintainers, they do a great job !!).
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.
However with SunOS and Open Look come about 40 MB of libraries , so I hope linux will not
go into that direction.
Helmut Geyer
From: mycroft@hal.gnu.ai.mit.edu (Charles Hannum)
Subject: Re: Unsharable Shared Libraries.
Date: 27 Feb 1993 04:45:06 GMT
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.
--
\ / Charles Hannum, mycroft@ai.mit.edu
/\ \ PGP public key available on request. MIME, AMS, NextMail accepted.
Scheme White heterosexual atheist male (WHAM) pride!
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
From: bsa@kf8nh.wariat.org
Subject: Re: Unsharable Shared Libraries.
Date: Mon, 1 Mar 1993 02:38:07 GMT
In article < 1mmrkiINN2g2@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>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.
I see you haven't looked at libc-4.3 yet. Dynamic linking for Linux exists
*now*. (With a few small bugs, now being fixed; blame the Xfree 1.2 folks for
jumping the gun.)
++Brandon
From: pmacdona@sanjuan (Peter MacDonald)
Subject: Re: Unsharable Shared Libraries.
Date: 1 Mar 93 16:38:54 GMT
In article <1993Mar1.023807.26914@kf8nh.wariat.org> bsa@kf8nh.wariat.org writes:
>In article <1mmrkiINN2g2@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>>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.
>
>I see you haven't looked at libc-4.3 yet. Dynamic linking for Linux exists
>*now*. (With a few small bugs, now being fixed; blame the Xfree 1.2 folks for
>jumping the gun.)
I am not sure why everyone keeps lamenting the fact that libc.4.3 was released
with bugs/early. It was tested, by me and a dozen others. But the bug is
subtle and intermitent, and some of us (me) have the same problem, due to flaky
memory, so never properly acredited the symptoms to libc. In fact, all I saw
was an *increase* in the frequency of core dumps/logouts. Noticed after the fact.
As for Xfree 1.2, I take some responsibility in rushing it along (mostly by
lobbying). The main reason was that I found out that the X 1.0 that SLS
had was an unofficial version that was not supposed to be released to the
general public, and that the Xfree developers (bless their souls) were a
little less than ecstatic about getting bug reports about a version that
was not supposed to be released.
So there you have it. Given the rate that SLS is spreading and growing,
it was very desirable to clean it up ASAP. And the fix for libc.4.3 will
just be downloading a new shared lib or two. So relax, and enjoy the ride...
Peter
From: hlu@eecs.wsu.edu (H.J. Lu)
Subject: Re: Unsharable Shared Libraries.
Date: Mon, 1 Mar 93 20:27:59 GMT
In article <1993Mar1.023807.26914@kf8nh.wariat.org>, bsa@kf8nh.wariat.org writes:
|> In article <1mmrkiINN2g2@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
|> >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.
|>
|> I see you haven't looked at libc-4.3 yet. Dynamic linking for Linux exists
|> *now*. (With a few small bugs, now being fixed; blame the Xfree 1.2 folks
^^^^^^^^^^^^^^^^^^^^^^^^^^
That is not what happened. It was the case of miscommunication. I don't
want to go into it. Maybe I am the one who should be blamed. After all, it
was I who released a buggy library :-(.
for
|> jumping the gun.)
|>
|> ++Brandon
H.J.
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Unsharable Shared Libraries.
Date: 1 Mar 93 23:19:38 GMT
In article < 1993Mar1.202759.6443@serval.net.wsu.edu> hlu@eecs.wsu.edu (H.J. Lu) writes:
>That is not what happened. It was the case of miscommunication. I don't
>want to go into it. Maybe I am the one who should be blamed. After all, it
>was I who released a buggy library :-(.
>H.J.
I don't think that anyone needs to be blamed. We have caught a number
of problems, some related to the DLL, some related to the iostream stuff, some
related to other patches, and it could have taken us months to locate all of
these things without a public release. My general impression is that the
problems with 4.3 are at the minor nuisance level of inconvenience.
-Eric
--
"When Grigor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a monstrous vermin."
-F. Kafka