dlopen z dwoma udostępnionymi bibliotekami, eksportującymi symbole

Question

Mam wspólną bibliotekę linuksową, foo.so, która jest ładowana z pliku wykonywalnego przy użyciu dlopen("foo.so", RTLD_NOW | RTLD_LOCAL). Z foo.so chciałbym pobrać inną bibliotekę, bar.so, która odwołuje się do symboli zdefiniowanych w foo.so, ale linker nie znajduje ich. Nie mogę zmienić RTLD_LOCAL na RTLD_GLOBAL, ponieważ nie mam źródła do pliku wykonywalnego wykonującego ładowanie. Pomyślałem, że -Wl,--export-dynamic podczas łączenia foo.so może pomóc, ale nie zastąpi lokalnej flagi do dlopen. Nowa funkcja widoczności atrybutów GCC nie wygląda tak, jakby oferowała odpowiedź.

Czy istnieje sposób, w jaki mogę polecić linkerowi, aby rozwiązał odwołania do niezdefiniowanych symboli w pasku.do tych definicji w foo.so, bez paska łączącego z -lfoo lub podobieństwem przenoszącym symbole do trzeciej biblioteki i łączącym oba foo i przeciwko niemu? Jedyne, co mi się zdarza, to dlopen foo.so z RTLD_GLOBAL z samego foo.so, a następnie dlopen bar.so, ale to uderza mnie jako trochę bałaganu. Dzięki.

Answer 1

Link foo.so przeciwko bar.so.

Po załadowaniu pliku wykonywalnego dlopen() s foo.so, bar.so.

Alternatywnie, poprawkę binarną do pliku wykonywalnego, aby dodać RTLD_GLOBAL do flag dla wywołania dlopen(). Kod będzie wyglądać

movl $2, 4(%esp)  # $2 == RTLD_NOW; RTLD_LOCAL is 0 
    movl $0xNNNNN, (%esp) # $0xNNNNN == &"foo.so" 
    call dlopen 

patchu go do movl $0x102, 4(%esp) zamiast (RTLD_GLOBAL == 0x100), i voila.

EDIT:
Jeśli znasz nazwę bar.so, a następnie można połączyć foo.so przeciwko "odgałęzienie" bar.so. Nie ma znaczenia, że ​​nie masz "prawdziwego" bar.so; najważniejsze jest to, że foo.so ma na nim zależność. W czasie wykonywania ta zależność spowoduje załadowanie bar.so po załadowaniu foo.so.