Mac: Jak wyeksportować symbole z pliku wykonywalnego?

Question

Piszę plik wykonywalny, który używa dlopen() (LoadLibrary() w systemie Windows), aby dynamicznie ładować bibliotekę współużytkowaną. Biblioteka współdzielona używa symboli z pliku wykonywalnego.

W systemie Windows jest to możliwe. Pliki wykonywalne mogą eksportować symbole: działają pliki declspec (dllexport) i .def. Łącznik, podczas tworzenia .exe, również tworzy plik .lib ("bibliotekę importu"), więc biblioteka DLL musi po prostu połączyć się z tym .lib.

W systemie Linux jest to również możliwe. Przepuszczam -Wl, -export_dynamic podczas budowania pliku wykonywalnego, aby eksportował swoje symbole.

W systemie Mac OS X, zamiast ... -Wl, -export_dynamic nie działa, ale jest -Wl, -exported_symbols_list, <filename><filename> gdzie znajduje się lista symboli do eksportu (rodzaj prostszej wersji plik .def). Ale budowanie wspólnej biblioteki nie jest tak proste: linker narzeka na nierozwiązane symbole.

Próbowałem włamać: zmieniono nazwę pliku wykonywalnego na lib <executable> .dylib, a po połączeniu z biblioteką udostępnioną przejąłem -l <executable>. Ale daje błąd "nie można połączyć z głównym plikiem wykonywalnym".

Ogólny problem polega na tym, że biblioteki współdzielone Linux mogą mieć nierozwiązane symbole, podczas gdy Windows i Mac OS X na to nie zezwalają. Ale system Windows ma "biblioteki importu", aby rozwiązać problemy z zależnościami, a Mac OS X najwyraźniej nie ...

Jak można to rozwiązać w systemie Mac OS X? Czy istnieje odpowiednik "biblioteki importu" (biblioteki pośredniczącej utworzonej przez linker systemu Windows podczas tworzenia pliku .dll, więc jeśli dowolny moduł musi dynamicznie łączyć się z .dll, jest powiązany z "biblioteką importu")? Lub jakieś inne rozwiązanie?

Answer 1

Samodzielny interpreter Lua obsługuje dynamiczne ładowanie (przez dlopen) współdzielonych bibliotek, które używają symboli z pliku wykonywalnego (API Lua). Podczas budowania nie jest używana specjalna flaga linku. Wspólne biblioteki są budowane przy użyciu tego zaklęcia:

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

Answer 2

Dziękuję, odpowiedź stymulować chęć zbadania różnicy między wiązkami i dylibs. I LD obsługi strona wymienić opcję o nazwie -bundle_loader

-bundle_loader wykonywalnego
Określa plik wykonywalny, który zostanie załadowany plik wyjściowy wiązka są ze sobą powiązane. Niezdefiniowane symbole z pakietu są sprawdzane pod kątem określonego pliku wykonywalnego, tak jak był to jeden dynamicznych bibliotek, z którymi pakiet był połączony.

(zauważ, że -bundle_loader zawiedzie podczas budowania dylib, to działa tylko z wiązek) Więc stary wiersz poleceń

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

został przekształcony

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

i wiązka wyjściowa rozwiązał niezdefiniowane symbole względem pliku wykonywalnego.