linux/gcc: funkcjonalność ldd z poziomu programu C/C++

Czy istnieje prosty i skuteczny sposób, aby wiedzieć, że dany dynamicznie połączony ELF brakuje wymaganego .so do uruchomienia, wszystko z wewnątrz Program C/C++?linux/gcc: funkcjonalność ldd z poziomu programu C/C++

Potrzebuję program o nieco podobnej funkcjonalności jak ldd, bez próby wykonania ELF, aby znaleźć zależności (met/unmet) w systemie. Być może zadając narzędzie ld-linux.so przez jakąś bibliotekę? (Jestem nowicjuszem w tej części linux =)

UWAGA: odczyt kodu źródłowego ldd nie był bardzo pomocny w moich intencjach: wydaje się, że w rzeczywistości jest ldd forking inny proces i realizacji programu.

Jeśli to nie jest możliwe, aby wiedzieć, że program ma niespełnione zależności bez wykonywania go, czy jest jakiś sposób, aby przynajmniej szybko podać wykaz .so to wymagane dla tego ELF wszystko od wewnątrz mojego programu?

góry dzięki =)

Źródło

2009-10-05 conejoroy

Czy masz dobry powód, dla którego nie wystarczy wywołać narzędzia ldd i przeanalizować jego wyjście? Pod Linuksem taka technika jest szeroko stosowana. – Juraj

Wolałbym nie wywoływać powłoki, aby wykonać cokolwiek innego niż mój własny program. Poza tym nie jest zbyt wydajne rozwidlanie, uruchamianie powłoki, itp. Tylko po to, aby wypróbować, czy plik wykonywalny będzie działał próbnie i błędnie ... ale tak , Podejrzewam, że wywoływanie ldd jest dobrym standardowym wyborem. – conejoroy

Przepraszam, to jest mit. Widelec wcale nie jest drogi, a większość wywołań exec *() nie używa powłoki do uruchomienia binarnego. Jest możliwe, że zabijesz więcej czasu, nurkując w wewnętrznych partiach LD-Linuksa w porównaniu do nakładki fork()/exec() dla wszystkich przyszłych wywołań razem. – Juraj

zgodnie ld.so(8), ustawiając zmienną środowiskową LD_TRACE_LOADED_OBJECTS do niepusty ciąg da ldd -jak wyników (zamiast wykonanie normalnie biblioteki binarnej lub biblioteki).

setenv("LD_TRACE_LOADED_OBJECTS", "1", 1); 
FILE *ldd = popen("/lib/libz.so");

Źródło

2009-10-05 16:26:39 ephemient

tak, da to dokładnie taką samą wydajność, jak ldd (cóż, być może ustawiając dodatkową parę envów więcej) w rzeczywistości ldd to nic innego jak twój kod ... ale oczywiście to rozwiązanie jest takie samo, jak wywoływanie ldd, które z kolei wywoła twój kod. Szukałem innego rozwiązania, może zapytałem ld-linux.so w inny, bardziej bezpośredni sposób .. – conejoroy

.. i bez wywoływania powłoki =) – conejoroy

Bez wywoływania powłoki jest łatwe - po prostu 'fork' i' exec' ('pipe' najpierw jeśli chcesz wyprowadzać i' fdopen' jeśli naprawdę chcesz 'FILE * ') zamiast' popen'. Jest to w zasadzie zapytanie do 'ld-linux.so' bez konieczności stosowania twardego kodu *, który *' ld-linux.so'. – ephemient

Czy próbowałeś dlopen funkcję? możesz go użyć do załadowania biblioteki dynamicznej (lub, dla twojego przypadku, do sprawdzenia, czy można załadować bibliotekę).

Mając listę potrzebnych bibliotek jest trudniejsze, przyjrzeć się handle_dynamic funkcji na readelf source

Źródło

2009-10-05 15:10:42

Ta funkcja jest interesująca, widzę rpath i inne parametry. Zbadam dalej, dzięki – conejoroy

linux/gcc: funkcjonalność ldd z poziomu programu C/C++

Odpowiedz

Powiązane problemy