Mailinglist Archive: opensuse-de (4628 mails)

[Ralf Corsepius <corsepiu@xxxxxxxxxxxxxx>]

Am Mon, 2002-09-02 um 09.31 schrieb Bernd Brodesser:
> Hallo Philipp,
>
> * Philipp Thomas schrieb am 02.Sep.2002:
> > B.Brodesser@xxxxxxxxxxx (Bernd Brodesser) [1 Sep 2002 11:24:33 +0200]:
>
> > > Die Frage ist, was passiert, wenn ein Programm gegen
> > > libname.so.<hauptversion>.<minorversion> gelinkt ist, der Anwender
> > > aber libname.so.<hauptversion>.<andereminorversion> hat.
>
> > Das Programm wird nicht laufen, da die Abhängigkeit nicht erfüllt ist.
> > Aber die einzigen Bibliotheken, die ich kenne und deren Soname die
> > volle Version besitzt sind die zu den binutils gehörenden Bibliotheken
> > (libbfd, lipopcodes). 
>
> Da haben wir anscheinend aneinander vorbeigeredet. Angenommen ein
> Programm ist auf libname.so.<hauptversion> gelinkt und
> libname.so.<hauptversion> ist ein SymLink (Oh, oh, hier hat das Wort
> link eine vollkommen andere Bedeutung) auf
> libname.so.<hauptversion>.<minorversion>. Ich installiere mir dieses
> Programm und ich habe auch libname.so.<hauptversion> bei mir ist es
> aber ein Symlink auf libname.so.<hauptversion>.<neuereminorversion>

Die Versionierung einer Library deren Nutzung durch ein Programm das von
Dir beschriebene Verhalten zeigt ist defekt, da per Definition alle
libxxx.X.Y und libxxx.X.(Y+n) (mit n >= 0) binär-kompatibel seien
_müssen_. 
 
> Wenn das Programm dann bei mir nicht läuft, dann könnte man sich das
> mit major- und minorversion auch schenken und nur eine
> Versionsnummer verteilen.
Richtig. 

Nur, ist es genau Sinn und Zweck der minor-Versionnumber genau dieses
Problem zu umgehen, da Programme normalerweise libxxx.X verlangen, und
es ihnen egal sein sollte, ob nun libxxx.X.Y oder libxxx.X.Z vorhanden
ist.

Oder umgekehr formuliert, die minor-Lib-Versionnumbers räumen
Lib-Entwicklern die Möglichkeit ein, Updates/Bug-Fixes oder
Erweiterungen von Libs herauszubringen, ohne die Binärkompatibilitärt zu
vernichten und User zu Upgrades zu zwingen.

Nur so ist es z.B. möglich, dass Programme, die gegen glibc-2.2.1
gelinkt sind auch noch unter glibc-2.2.3 laufen.

(Eine detailierte Diskussion dieses Themas ist in libtool.info zu
finden).

> > > Und was ist, wenn er eine höhere hauptversion hat?
> >
> > Auch dann funktioniert es nicht und das ist gut so! Eben weil dem so
> > ist, können Programme koexistieren, die unterschiedliche Versionen der
> > gleichen Bibliothek verwenden.
>
> Wieso? Wenn alles auch mit der neusten Version liefe, dann gäb es
> doch auch keine Probleme.
In einer idealen Welt gäbe es diese Probleme auch nicht ;) Leider ist
die Welt nicht ideal, ausserdem gehen viele Autoren von Libs gehen recht
sorglos mit der Lib-Versionierung um.

> > > > Die lib<name>.so Dateien werden i.d.R. ausschliesslich vom statischen
> > > > Linker zum Erstellen des Programmes benötigt.
> > >
> > > Du meinst lib<name>.a so steht für shared object, a für archiv.
> >
> > Nein, ich meinte durchaus lib<name>.so. Beachte, dass ich vom
> > statischen Linker, also dem normalen ld und nicht vom statischen
> > Linken sprach.
>
> Huch, ich kenne nur den ld. 
Das ist der statische Linker

> Was ist denn ein dynamischer Linker?
Auch Runtime-Linker seltener auch Startup-Linker genannt. Er durchsucht,
beim Start von dynamisch gelinkten Programmen, diese nach dynamisch
gelinkten Libs und lädt sie hinzu. (Siehe man ld.so).

Ralf