dlopen - niezdefiniowany błąd symbol

Question

Używam dlopen załadować biblioteki współdzielonej w czasie wykonywania

dlopen("SharedLibarary1.so", RTLD_NOW | RTLD_GLOBAL); 

W tym obiektem udostępnionym odsyłam do const char * zdefiniowanej w innej udostępnionej biblioteki „SharedLibarary2.so”.

Plik wykonywalny i obie biblioteki są zbudowane przy użyciu -rdynamic.

Ale nadal otrzymuję błąd czasu wykonywania, gdy używam dlopen: "/usr/lib/SharedLibarary1.so: niezdefiniowany symbol" i wskazuje na zniekształcone znaki stałe * ma niezdefiniowany symbol.

Whith GDB "udział informacyjny" Widzę, że druga biblioteka nie jest załadowana w punkcie błędu.

Jak dotąd ten problem zniknie, jeśli zrobię dlopen w drugiej bibliotece, zanim zrobię to w pierwszej bibliotece.

Czy istnieje lepszy sposób wymuszenia na ładowarce załadowania drugiej biblioteki dla nierozwiązanego symbolu?

Answer 1

Podczas tworzenia współużytkowanej biblioteki można połączyć inne, np. jak

gcc -shared -rdynamic lib1*.pic.o -lshared2 -o SharedLibrary1.so 

Następnie skontaktować się z ldd SharedLibrary1.so

(patrz przykład na wyjściu ldd w systemie użytkownika libgtk-3.so.0 dla przykładu)

% ldd /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 
linux-vdso.so.1 => (0x00007fff6afff000) 
libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007f0572628000) 
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f0572424000) 
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f057221b000) 
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f057200e000) 
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f0571cd2000) 
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f0571ac2000) 
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f05718c0000) 
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f05716be000) 
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f05714b7000) 
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f0571294000) 
libcairo-gobject.so.2 => /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2 (0x00007f057108b000) 
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f0570d91000) 
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f0570b71000) 
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f0570946000) 
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f05706f8000) 
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f0570459000) 
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f0570222000) 
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f056fece000) 
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f056fc7e000) 
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f056f986000) 
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f056f703000) 
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f056f4e7000) 
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f056f160000) 
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f056ef4c000) 
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f056ed4a000) 
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f056eb42000) 
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f056e937000) 
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f056e733000) 
/lib64/ld-linux-x86-64.so.2 (0x00007f0572f57000) 
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f056e512000) 
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f056e28c000) 
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f056e064000) 
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f056de61000) 
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f056dc57000) 
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f056da4d000) 
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f056d836000) 
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f056d60b000) 
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f056d3eb000) 
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f056d1d5000) 
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f056cfd2000) 
libffi.so.5 => /usr/lib/x86_64-linux-gnu/libffi.so.5 (0x00007f056cdc5000) 
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f056cb87000) 
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f056c983000) 
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f056c77e000) 

Answer 2

Jeśli to możliwe, należy połączyć każdą wspólną bibliotekę dlopen() z argumentami linkera, aby wymusić rozwiązanie wszystkich swoich symboli podczas tworzenia biblioteki. W ten sposób możesz być bardziej pewny, że wiesz, skąd pochodzą wszystkie twoje symbole. ("-z defs" na przykład pod Linux x86)

W ten sposób, jeśli dodasz nowy plik źródłowy, ale zapomnisz dodać obiekt do linku, nie będziesz drapał się po głowie ze względu na środowisko uruchomieniowe błąd z dlopen/dlsym.