Hallo , vielen herzlichen dank jetzt weiss ich auch wo ich anfangen soll :-) bin nämlich ziemlich neu bei Linux-Programmirung aber habe lange Zeit unter Windows entwickelt. wenn da referencen gibt , bücher oder so was ähnliches würde mich sofort daran machen. viel danke noch mal an alle besonders an ' Ralf ' Bis dann Mohammad Am Montag, 20. Januar 2003 17:01 schrieb Ralf Corsepius:
On Mon, 2003-01-20 at 16:03, mohammad Gharbalchi wrote:
Hallo und vielen Dank Reiner , so weit ich informiert bin shared libs sind dafür da um den Speicherbedarf und ladezeit der Bibliotheken gering zuhalten, da diese von mehrere Programmen parallel benutzt werden können.
Nicht nur, ...
Selbst bei der Windofs versionen hat man ständig bis vor kurzem die VB-Bibliotheken gleich mit dem programm liefern müssen, da diese von version zu version unterschiedlich waren.
Das ist ein wesentlicher Unterschied zw. Unix/Linux und Windows ;)
Dies hat den hintergrund, dass der linker so genannte Symbol adressen berechnet und festgehalten hat, jetzt geht man her und ändert den Bibiothek so stimmen die alle adressen nicht mehr und daher können die programme ohne damaligen (Linkzeit) bibliothek nicht funktionieren. Diese wird noch klarer wenn man bei bilden eines bibliothekes Listing mit erzeugt und nach kurze änderung es vergleicht.
Ich nehme an Du beziehst Dich auf DLLs (Auch diese gab es mal unter Linux - Zu Zeiten von libc4, IIRC; Dateiextension *.sa).
Was hier unter "Shared-Libs" gemeint ist, bezeichnen manche als DSO (Dynamically Shared Objects; Dateiextension *.so). Sie sind nicht nur "shared" sondern auch dynamisch, d.h. sie werden nicht nur (wie DLLs) zwischen mehreren Programmen im Speicher geteilt, sondern zusätzlich noch erst beim Programmstart vom dynamischen Linker (man ld.so, man ldd) dem Programm hinzugebunden.
Aber das mit dem nachliefern der Teile als so genannten Komponents (M$) ist was anderes. Da diese über Interface ansprechbar sind und der Linker merkt sich ein Nummer (Interface ID) und spricht diese anhand sein eindeutigen ID , welches unter M$ registry wieder zufinden ist. hier kann man auch gleich nachschlagen welche Interfaces noch zu einem Bibliothek freigegeben sind. Diese zugriff auf Interfaces geschieht nur im Laufzeit und nicht bei Linken des programmes.
Wie bei Linux Shared-Libs.
Wenn man Sharedlibraries auf diesem weg einsetzen kann, dann habe das gefunden wasich seit lange Zeit suche.
Wenn es "nur" um den Aspekt "Interface" geht, ja (Vgl info libtool).
Eine frage noch hast du mal versucht auf diese weise vorzu gehen? Ich meine erst ein bibliothek bilden, dann das programm linken.
Ja, täglich ;) Das ist der Normalfall.
Jetzt wird das bibliothek geändert , und neu gebildet. die frage lautet jetzt ob das programm ohne neu zulinken funktioniert ? ????
Mit Shared-Libs, sofern sich das Interface der Lib nicht inkompatibel geändert hat, ja. (Siehe info libtool, Stichwort Versioning).
wennja dann braucht man ja das Programm bei Update eines programmes nicht mit zuliefern oder ?
Du meinst, Du tauscht die Bibliothek unterhalb eines Programmes aus, und das Programm funktioniert weiterhin? Dann ja.
Ralf