Łatwe sprawdzenie nierozwiązanych symboli w bibliotekach współdzielonych?

Piszę dość dużą bibliotekę współdzielonych obiektów C ++ i napotkałem mały problem, który sprawia, że ​​debugowanie jest uciążliwe:

Jeśli zdefiniuję funkcję / metodę w pliku nagłówkowym i zapomnę utworzyć dla niej kod pośredniczący (podczas programowania), ponieważ tworzę jako współdzieloną bibliotekę obiektów, a nie plik wykonywalny, nie pojawiają się żadne błędy w czasie kompilacji, informujące mnie, że mam zapomniał zaimplementować tę funkcję. Jedyny sposób, w jaki dowiaduję się, że coś jest nie tak, to w czasie wykonywania, kiedy w końcu aplikacja łącząca się z tą biblioteką wypada z błędem „niezdefiniowany symbol”.

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

Jednym z rozwiązań, które wymyśliłem, jest uruchomienie skompilowanej biblioteki w nm -C -Ucelu uzyskania odszyfrowanej listy wszystkich niezdefiniowanych odniesień. Problem polega na tym, że pojawia się również lista wszystkich odniesień, które znajdują się w innych bibliotekach, takich jak GLibC, do których oczywiście zostanie dołączony link wraz z tą biblioteką podczas składania ostatecznej aplikacji. Byłoby możliwe użycie wyjścia nmdo grepprzez wszystkie moje pliki nagłówkowe i sprawdzenie, czy którakolwiek z nazw odpowiada… ale to wydaje się szalone. Z pewnością nie jest to rzadki problem i istnieje lepszy sposób jego rozwiązania?

Sprawdź opcję konsolidatora -z defs/ --no-undefined. Podczas tworzenia obiektu współużytkowanego spowoduje to, że łącze nie powiedzie się, jeśli istnieją nierozwiązane symbole.

Jeśli używasz gcc do wywołania konsolidatora, użyjesz -Wlopcji kompilatora , aby przekazać opcję do konsolidatora:

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

Jako przykład rozważ 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 wbudujesz to we współdzielony obiekt, to się powiedzie:

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

Ale jeśli dodasz -z defs, łącze zawiedzie i poinformuje Cię o brakującym symbolu:

> 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

W systemie Linux (którego prawdopodobnie używasz) ldd -r a.outpowinien dać ci dokładnie odpowiedź, której szukasz.

UPDATE: trywialny sposób tworzenia, a.outna podstawie którego można sprawdzić:

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

A co z zestawem testowym? Tworzysz pozorowane pliki wykonywalne, które odsyłają do potrzebnych symboli. Jeśli łączenie się nie powiedzie, oznacza to, że interfejs biblioteki jest niekompletny.

Miałem kiedyś ten sam problem. Pracowałem nad modelem komponentów w C ++ i oczywiście komponenty powinny ładować się dynamicznie w czasie wykonywania. Przychodzą mi na myśl trzy rozwiązania, które zastosowałem:

1. Poświęć trochę czasu na zdefiniowanie systemu kompilacji, który będzie w stanie kompilować statycznie. Stracisz trochę czasu na inżynierię, ale zaoszczędzi ci to dużo czasu na łapanie tych irytujących błędów w czasie wykonywania.
2. Pogrupuj swoje funkcje w dobrze znane i dobrze zrozumiałe sekcje, aby móc grupować funkcje / kody pośredniczące, aby mieć pewność, że każda odpowiadająca im funkcja ma swój kod pośredniczący. Jeśli poświęcisz trochę czasu na dobre udokumentowanie tego, być może możesz napisać skrypt, który sprawdzi definicje (na przykład poprzez jego komentarze doxygen) i sprawdzić odpowiedni plik .cpp.
3. Wykonaj kilka testowych plików wykonywalnych, które ładują ten sam zestaw bibliotek i określ flagę RTLD_NOW na dlopen (jeśli jesteś pod * NIX). Będą sygnalizować brakujące symbole.

Mam nadzieję, że to pomoże.