Łatwe sprawdzanie nierozwiązanych symboli w udostępnianych bibliotekach?

Question

Piszę dość dużą bibliotekę obiektów współdzielonych w C++ i natknąłem się na mały problem, który sprawia, że ​​debugowanie bólu:

Jeśli zdefiniuję funkcję/metodę w pliku nagłówkowym i zapomnę utworzyć skrót do to (podczas programowania), ponieważ buduję jako bibliotekę obiektów wspólnych, a nie jako plik wykonywalny, podczas kompilacji nie pojawiają się żadne błędy mówiące mi, że zapomniałem wprowadzić tę funkcję. Jedyny sposób, aby dowiedzieć się, że coś jest nie tak, jest w czasie wykonywania, kiedy ostatecznie aplikacja łącząca się z tą biblioteką przewraca się z błędem "niezdefiniowanego symbolu".

Szukam łatwego sposobu sprawdzenia, czy mam wszystkie symbole potrzebne w czasie kompilacji, być może coś, co mogę dodać do mojego pliku Makefile.

Jednym z rozwiązań, które udało mi się wymyślić, jest uruchomienie skompilowanej biblioteki przez nm -C -U, aby uzyskać demangowaną listę wszystkich nieokreślonych odniesień. Problem polega również na tym, że pojawia się lista wszystkich odniesień znajdujących się w innych bibliotekach, takich jak GLibC, które oczywiście będą połączone razem z tą biblioteką po złożeniu ostatecznej aplikacji. Możliwe byłoby użycie wyjścia z nm do grep przez wszystkie moje pliki nagłówkowe i zobaczenie, czy któraś z nazw odpowiada ... ale to wydaje się szalone. Z pewnością nie jest to rzadkość i istnieje lepszy sposób na jej rozwiązanie?

Answer 1

Zapoznaj się z rozwiązaniem łącznik -z defs/--no-undefined. Podczas tworzenia obiektu współużytkowanego spowoduje to niepowodzenie łącza, jeśli istnieją nierozwiązane symbole.

Jeśli używasz gcc powołać łącznika, można użyć kompilatora -Wl opcję, aby przejść do opcji linkera:

gcc -shared ... -Wl,-z,defs 

Jako przykład rozważmy następujący plik:

#include <stdio.h> 

void forgot_to_define(FILE *fp); 

void doit(const char *filename) 
{ 
    FILE *fp = fopen(filename, "r"); 
    if (fp != NULL) 
    { 
     forgot_to_define(fp); 
     fclose(fp); 
    } 
} 

teraz, jeśli budować, że do obiektu udostępnionego, będzie to sukces:

> gcc -shared -fPIC -o libsilly.so silly.c && echo succeeded || echo failed 
succeeded 

Ale jeśli dodać -z defs, link nie powiedzie się i opowiedzieć o swojej brakującej symbolem:

> gcc -shared -fPIC -o libsilly.so silly.c -Wl,-z,defs && echo succeeded || echo failed 
/tmp/cccIwwbn.o: In function `doit': 
silly.c:(.text+0x2c): undefined reference to `forgot_to_define' 
collect2: ld returned 1 exit status 
failed 

Answer 2

Co z zestawem testowym? Tworzysz fałszywe pliki wykonywalne, które łączą się z symbolami, których potrzebujesz. Jeśli połączenie nie powiedzie się, oznacza to, że twój interfejs biblioteki jest niekompletny.

Answer 3

Raz miałem ten sam problem. Opracowywałam model komponentu w C++ i oczywiście komponenty powinny ładować się dynamicznie w środowisku wykonawczym. Przyszły mi do głowy trzy rozwiązania: te, które zastosowałem:

1. Poświęć trochę czasu na zdefiniowanie systemu kompilacji, który jest w stanie skompilować statycznie. Stracisz trochę czasu na jego inżynierię, ale zaoszczędzi ci to wiele czasu na złapaniu tych denerwujących błędów w czasie wykonywania.
2. Grupuj swoje funkcje w dobrze znanych i zrozumiałych sekcjach, dzięki czemu możesz grupować funkcje/kody pośredniczące, aby mieć pewność, że każda odpowiednia funkcja ma swój skrót. Jeśli poświęcisz sporo czasu na udokumentowanie tego, możesz napisać skrypt sprawdzający definicje (np. Poprzez swoje komentarze doxygen) i sprawdzić odpowiedni plik .cpp.
3. Wykonaj kilka testowych plików wykonywalnych, które wczytują ten sam zestaw bibliotek i określ flagę RTLD_NOW na dlopen (jeśli jesteś w * NIX). Będą sygnalizować brakujące symbole.

Nadzieję, że pomaga.

Answer 4

W systemie Linux (którego wydaje się, że się używasz) ldd -r a.out powinien dać ci dokładnie taką odpowiedź, której szukasz.

UPDATE: trywialny sposób, aby utworzyć a.out przeciwko którym do sprawdzenia:

echo "int main() { return 0; }" | g++ -xc++ - ./libMySharedLib.so 
ldd -r ./a.out