On Fri, Nov 17, 2000 at 04:59:01PM +0100, Konrad Rosenbaum wrote:
Als s.object bezeichnet man das Teil, wenn man es gerade kompiliert oder _nur_ zur Laufzeit laedt.
Als s.lib bezeichnet man es, wenn es vom ELF-Loader im Kernel gerade geladen wird.
Falsche Defi. Gegenbeispiel: Bei a.out-Linux gibt es auch shared libs und diese werden nicht von einem "ELF-Loader" in den Kernel geladen. q.e.q. Der Begriff "shared lib" sagt UEBERHAUPT NICHTS über das Wann und Wie des Linkens und Ladens aus. Shared sagt einfach nur, dass die Lib bei Nutzung durch mehrere Anwendungen nur einmal im Speicher rumlungert.
Du kannst also auch eine System mit shared libs bauen, die in jedem Binary (also mehrmals) vorhanden sind und trotzdem shared sind. Natuerlich ist das so unpraktisch, dass das kein Mensch macht. Zur Klaerung der Begriffe ist die Betrachtung aber sinnvoll.
Was du zu erklaeren versuchst ist eine "dynamisch ladbare Bibliothek" Das diese meist gleichzeitig auch shared lib ist, liegt aus praktischen Gruenden auf der Hand, ist aber nicht zwingend.
Also nur Haarspalterei, da es sich um die selbe Datei handelt.
Naja, so langsam wurde in diesem Thread alles durcheinanderegehauen.
mit .so Dateien habe ich zwei Moeglichkeiten: a) sie per Headerdatei einbinden und den Linker einen Eintrag in mein Program machen lassen, der von Kern als "ladt das Ding fuer mich, weil ich zu faul dazu bin" interpretiert wird. b) ich oeffne sie per dlopen(3) und lasse mir (Funktions-)Pointer auf die Symbole darin geben und rufe die entsprechenden Pointer auf
Der Witz bei Variante b) ist mMn, dass man eigentlich nur den Namen einer Funktion kennen muss (sowas wie ListFunctionNames()) und damit dann Funktionen laden kann, deren Namen zur Compilezeit des Hauptprogramms noch gar nicht bekannt waren. Das geht mit dem Mechanismus in a) nicht.
(ich habe Mechanismus b) noch nicht benutzt. Stimmt das, was ich hier gesagt habe? Stefan G.???)
Reinhard