2010-10-17 4 views
6

Ich schreibe eine ausführbare Datei, die dlopen() (LoadLibrary() unter Windows) verwendet, um eine gemeinsam genutzte Bibliothek dynamisch zu laden. Die gemeinsam genutzte Bibliothek verwendet Symbole aus der ausführbaren Datei.Mac: Wie man Symbole aus einer ausführbaren Datei exportiert?

In Windows ist dies möglich. Ausführbare Dateien können Symbole exportieren: declspec (dllexport) und .def-Dateien funktionieren beide. Der Linker erstellt beim Erstellen der EXE-Datei auch die .lib-Datei (die "Importbibliothek"), sodass die DLL nur mit dieser .lib-Datei verknüpft werden muss.

In Linux ist dies auch möglich. Ich übergebe -Wl, -export_dynamic beim Erstellen der ausführbaren Datei, so dass sie ihre Symbole exportiert.

Unter Mac OS X, statt ... -Wl, -export_dynamic funktioniert nicht, aber es gibt -Wl, -exported_symbols_list, <filename> wo <filename> eine Liste von Symbolen zu exportieren (eine Art einer einfacheren Version eines .def-Datei). Aber das Erstellen der gemeinsamen Bibliothek ist nicht so einfach: Der Linker beschwert sich über die ungelösten Symbole.

Ich probierte einen Hack: benannte die ausführbare Datei in lib <executable> .dylib um und, als ich die shared library verlinkte, übergab ich -l <executable>. Aber es gibt den Fehler "kann nicht mit einer Hauptdatei verbinden".

Das allgemeine Problem ist, dass gemeinsam genutzte Linux-Bibliotheken nicht aufgelöste Symbole haben können, während Windows und Mac OS X dies nicht zulassen. Aber Windows hat "Bibliotheken importieren", um Symbole gegen Abhängigkeiten aufzulösen, und Mac OS X anscheinend nicht ...

Wie kann dies unter Mac OS X gelöst werden? Gibt es eine äquivalente "Importbibliothek" (die Stubbibliothek, die vom Windows-Linker beim Erstellen einer DLL erstellt wird. Wenn also ein Modul dynamisch mit der DLL verknüpft werden muss, wird es mit der "Importbibliothek" verknüpft)? Oder eine andere Lösung?

Antwort

5

Der eigenständige Lua-Interpreter unterstützt das dynamische Laden (über dlopen) von gemeinsam genutzten Bibliotheken, die Symbole aus der ausführbaren Datei verwenden (die Lua-API). Beim Erstellen wird kein spezielles Link-Flag verwendet. Die gemeinsam genutzten Bibliotheken werden diese Beschwörung gebaut mit:

env MACOSX_DEPLOYMENT_TARGET=10.3 gcc -bundle -undefined dynamic_lookup -o random.so lrandom.o 
+1

BTW, "env MACOSX_DEPLOYMENT_TARGET = 10.3" wird nicht für 10.5 und höher benötigt. – lhf

4

Vielen Dank, Ihre Antwort den Wunsch angeregt, den Unterschied zwischen Bündel und dylibs zu untersuchen. Und Handbuch Seite ld erwähnt eine -bundle_loader

genannt Option

-bundle_loader ausführbare
Diese die ausführbare Datei gibt an, dass das Bündel Ausgabedatei verknüpft werden geladen werden. Nicht definierte Symbole aus dem Bundle werden mit der angegebenen ausführbaren Datei verglichen, so wie sie der dynamischen Bibliotheken war, mit denen das Bundle verbunden war.

(beachten, dass -bundle_loader schlägt fehl, wenn ein dylib Gebäude, es funktioniert nur mit Bundles) So der alte Kommandozeile

cc -shared -o <output>.so <input>.c 

in

gedreht wurde
cc -bundle -bundle_loader <executable> -o <output>.so <input>.c 

und das Ausgangsbündel löste seine undefinierten Symbole gegen die ausführbaren Dateien.