On Fri, Nov 17, 2000 at 10:47:24PM +0100, Konrad Rosenbaum wrote:
On Friday 17 November 2000 19:57, Reinhard Foerster wrote:
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.
[das heisst q.e.d. - oder?]
ja, Tippfehler, sorry
Wer hat was von "in den Kernel" gesagt? Der ELF Loader sitzt nur im Kernel, legt die Daten aber in den Userspace.
Du hast gesagt "vom ELF-Loader im Kernel gerade geladen", und das ist numal keine Defi fuer shared fuer shared libs.
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.
Irgendwie versuchen wir hier mit unterschiedlichen Worten das selbe zu sagen...
Den Eindruck habe ich nicht.
Du kannst also auch eine System mit shared libs bauen, die in jedem Binary (also mehrmals) vorhanden sind und trotzdem shared sind.
(Deswegen _shared_ lib oder? ;-) )
aha
Haeh? Erklaer mal anhand von Dateien und Funktionen was Du meinst.
Boah, ich schreibe doch schon Romane.
Natuerlich ist das so unpraktisch, dass das kein Mensch macht. Zur Klaerung der Begriffe ist die Betrachtung aber sinnvoll.
Erklaer mal.
Habe ich eben gemacht. du hast den relevanten Teil nur nicht gequotet.
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.
Wie jetzt? DLL (Du nennst es deutsch "dynamisch ladbare Bibliothek") und shared lib und shared object sind das selbe, die Begriffe sagen das selbe aus, sie haben den selben Zweck, die Dateien sehen gleich aus (beide koennen a.out oder WinDLL oder ELF oder xyz_et_cetera sein).
Sorry, so langsam habe ich den Eindruck, dass du nicht lesen kannst oder willst. Oben steht von mir
Das diese meist gleichzeitig auch shared lib ist
wobei ^^^^^ das fuer "dynamisch ladbare Bibliothek" steht - OK?
Wie kannst du mir da unterstellen, das ich "dynamisch ladbare Bibliotheken" und shared libs als das gleiche darstelle, wenn ich doch extra hinschreibe, dass sie lediglich _meist_ zusammen auftreten. Ich habe in dem ganzen Thread dafuer geworben, diese beiden Begriffe auseinander zu halten. Und nun faengst du wieder von vorn an. Ich bekommem echt die Krise. Ohne ordentliches Lesen der Argumente anderer führt die Dikussion zu nichts.
Kurz: sieht aus wie Rollmops, schmeckt wie Rollmops, ist Rollmops. ;-)
Na toll.
(ich habe Mechanismus b) noch nicht benutzt. Stimmt das, was ich hier gesagt habe? Stefan G.???)Im Grunde ist es richtig, aber Du solltest auch wissen, welche Parameter Du brauchst, sonst bekommst Du einen netten SIGSEGV (auch unter dem Pseudonym "signal 11" bekannt). Es funktioniert etwa so:
Die Parameter muessen natuerlich dann genau wie die Namen der Funktionen ueber andere vordefinierte Funktionen abfragbar sein.
#include <dlfcn.h>
... void *handle=dlopen("libNixWeiter.so",RTLD_GLOBAL|RTLD_NOW);
if(handle==NULL)/*is schiefgegangen, keine libNixWeiter vorhanden*/ exit(1);
void (*somefunc)()=dlsym(handle,"soEineFunktion");
if(somefunc!=NULL) /*rufen wir das Teil mal auf:*/ somefunc();
/*aus der Spuk:*/ dlclose(handle);
Ja - das ist die Billig-Variante, bei der alle Funktionsnamen bekannt sein muessen. Dafuer wuerde ich nicht dl*() verwenden. Ich wollte dann z.B. ueber "soEineFunktion" ermitteln, was libNixWeiter.so noch so alles anbietet (Funktionsnamen+Parameter), davon dann wieder per dlsym() die Adressen bekommen und die Funktionen nutzen. Erst dann sehe ich eine Sinn in der Nutzung von dl*().
Reinhard