Der Shared Library-Konstruktor wird nicht ausgeführt

8

Ich habe das folgende Problem. Ich schreibe eine gemeinsame Bibliothek

%Vor%

Und kompilieren Sie es mit

gcc -c -fPIC testlib.c -o testlib.o

ld -shared -o libtest.so testlib.o

Dann füge ich es in ein Testprogramm

ein %Vor%

was ich kompiliere und benutze

gcc testprog.c -o Testprog -L. -ltest

LD_LIBRARY_PATH =. ./testprog

Dann ist die Ausgabe durch

gegeben

2.0000000000e + 01

bedeutet, dass der Konstruktor / Destruktor nicht ausgeführt wird. Auf der anderen Seite, wenn ich

kompiliere

ar rvs testlib.a testlib.o

gcc testprog.c testlib.a -o testprog

Die Ausgabe des Programms erfolgt durch

Testprog initialisiert 2.0000000000e + 01 aufgeräumt

Warum werden die Konstruktoren nicht ausgeführt, wenn die Bibliothek dynamisch verknüpft ist?

Ich verwende die folgenden Versionen

GNU ld (GNU Binutils; openSUSE 11.3) 2.20.0.20100122-6 GCC-Version 4.5.0 20100604 [gcc-4_5-Zweig Revision 160292] (SUSE Linux)

Vielen Dank im Voraus für Ihre Hilfe!

Bearbeitet: 2011-04-13, 11:05

Vielen Dank Luxifer,

Das Dokument hat indirekt geholfen! Der magische Hinweis war, dass man den Linker über den Compiler einbinden sollte ...

  

gcc -fPIC testlib.c -shared   -Wl, -soname, libtest.so -o libtest.so

funktioniert !!!

    
rd478qx 13.04.2011, 08:09
quelle

2 Antworten

-2

Dieser Text dient als Referenz, aber ich komme aus Bequemlichkeit in Ihr Büro:)

Ich bin kein Experte auf diesem Gebiet, aber eine schnelle Google-Suche gab mir dies . Lies nur den Anfang des Dokuments und wenn ich es richtig verstanden habe, ist das Problem:

Statisch verbunden ist Ihr Programm zur Ausführungszeit in sich geschlossen ... es enthält die gesamte Bibliothek und es wird vollständig in den Speicher geladen, wenn Sie es ausführen.

Dynamisch verknüpft, wenn die Bibliotheksfunktion zum Ausführungszeitpunkt von Ihrem Programm aufgerufen wird, versucht der Linker, alle nicht aufgelösten Verweise auf Funktionen aufzulösen, indem er nach einer Implementierung in einer Bibliothek sucht. Wenn ja, lädt es diese Implementierung, d.h. nur den Funktionscode.

Wenn ich das richtig mache und der dynamische Linker nur Teile von Bibliotheken lädt, d. h. benötigte Funktionen, und nicht die gesamte Bibliothek, würde dies erklären, warum Ihr Konstruktor nicht aufgerufen wird, wenn Ihre Bibliothek dynamisch verknüpft ist.

    
luxifer 13.04.2011, 08:36
quelle
4

Die Gcc -Konstruktor -Handhabung ist nicht dasselbe wie die ELF-Konstruktorbehandlung, sondern sie sitzt darüber. Um zu arbeiten, müssen Sie den Glue-Code, der in den Startdateien von gcc bereitgestellt wird, verlinken.

Der einfachste Weg ist die Verknüpfung mit gcc:

%Vor%     
Simon Richter 13.04.2011 09:27
quelle