GCC/Linux: dodanie biblioteki statycznej do .so?

Question

Mam program, który implementuje system wtyczek przez dynamiczne ładowanie funkcji z niektórych plugin_name.so (jak zwykle).

Ale z kolei mam statyczną bibliotekę "pomocnika" (pozwala wywołać ją helper.a), której funkcje są używane zarówno z głównego programu, jak i głównej funkcji wtyczki. Nie muszą w żaden sposób współdziałać, są tylko funkcjami pomocniczymi do manipulowania tekstem i takimi.

Ten program, po uruchomieniu, nie może zostać ponownie załadowany lub uruchomiony ponownie, dlatego oczekuję nowej funkcji "pomocnika" z wtyczki, a nie z głównego programu.

Więc moim zadaniem jest ... czy można wymusić ten "kod funkcji wtyczki" w .so, aby użyć (statycznie połączyć z?) Inną (prawdopodobnie nowszą) wersję "pomocnika" niż główny program?

Jak można to zrobić? być może przez statyczne łączenie lub w inny sposób dodawanie helper.a do plugin_name.so?

Answer 1

Odpowiedź Nicka Meyera jest poprawna w systemach Windows i AIX, ale jest mało prawdopodobne, aby była poprawna na każdej innej platformie UNIX domyślnie.

Na większości platform UNIX ładowarka wykonawcze utrzymuje jednolitej przestrzeni nazwa wszystkich symboli, więc jeśli zdefiniować foo_helper w a.out, a także w plugin.so, a następnie zadzwonić foo_helper z zarówno pierwsza definicja widoczny na starcie program ładujący (zwykle od a.out) jest używany domyślnie dla połączeń zarówno.

Ponadto obraz jest skomplikowana przez fakt, że foo_helper nie mogą być wywożone ze a.out (a zatem mogą być niewidoczne dla ładowacza wykonawczego), chyba że używasz -rdynamic flagę lub kilka inne współdzielone referencje IT bibliotece. Innymi słowy, rzeczy mogą pojawiać do pracy jak Nick je opisał, to dodajesz wspólną bibliotekę do linii łączącej a.out i nie działają już w ten sposób.

Na platformach ELF (takich jak Linux) masz dużą kontrolę nad widocznością i wiązaniem symboli. Zobacz opis strony man -fvisibility=hidden i -rdynamic w GCC, a także -Bsymbolic w stronie man linkera.

Większość innych platform UNIX również ma możliwość kontrolowania powiązań symboli, ale jest to z konieczności zależne od platformy.

Answer 2

Jeśli program główny i biblioteka dynamiczna są statycznie połączone z helper.a, to nie powinieneś się martwić o mieszanie wersji helper.a (o ile nie robisz takich rzeczy jak wskaźniki pasujące przydzielone w helperie .a między granicami .exe i .so).

Kod wymagany w pliku helper.a jest wstawiany do faktycznego pliku binarnego, gdy jest on połączony z nim. Więc kiedy wywołasz helper.a z .exe, będziesz wykonywał kod z segmentu kodu twojego pliku wykonywalnego, a kiedy wywołasz helper.a z .so, będziesz wykonywał kod z części przestrzeń adresowa, w której plik .so został załadowany. Nawet jeśli wywołujesz tę samą funkcję w helper.a, wywołujesz dwa różne "wystąpienia" tej funkcji w zależności od tego, czy wywołanie zostało wykonane z pliku .exe, czy z .so.

Answer 3

Myślę, że to pytanie jest takie samo jak twoje.How to force symbols from a static library to be included in a shared library build?

Opcja -wholes-archive linker powinna to zrobić. Używałbyś go jako np.

gcc -o libmyshared.so foo.o -lanothersharedlib -Wl, - całe archiwum -lmystaticlib

i to działa na mnie.