Accessing .so libraries using dlopen() throws undefined symbol error
I’m trying to dynamically load a camera library .so file into a Linux executable to gain access to simple camera functions. I’m attempting to do this by:
if ( (newHandle = dlopen("./libCamera.so",RTLD_LAZY | RTLD_GLOBAL)) == NULL ) However this fails and I receive the following output: «Could not open file : libCamera.so: undefined symbol: ZTVN10_cxxabiv117__class_type_infoE» How do I find out what symbols it is relying on?
4 Answers 4
Most likely, libCamera.so uses a symbol defined in a shared library without depending on that library.
- Find a culprit. Take a real executable which links against libCamera.so (and it works). List its dependencies with ldd /path/to/executable . Among them should be a library which has a definition for ZTVN10_cxxabiv117__class_type_infoE (use grep to select likely candidates, nm -D on a library to be sure). That library won’t be in the list shown by ldd ./libCamera.so .
- Solve a problem. Load the library found in step 1 by dlopen first (use RTLD_GLOBAL there as well).
- If there is a problem with another symbol, goto step 1.
- If newly-added libraries have the same problem too, goto step 1.
- Tell library authors to please fix their linking.
It could also happen that one of the prerequisites in ldd ./libCamera.so got upgraded and lost a symbol definition (maybe it was recompiled with a compiler which does name mangling differently). Then you won’t find the culprit in step 1, and there is no solution but downgrading something again.
The ldd command can be used to display shared library dependencies.
Once you know the dependencies, you can use nm to show the symbols in each library.
I saw a function listed in nm -DC libCamera.so but it was still undefined. In the end it turned out that in the .h file one of the arguments was const & in the .cpp it was not const which caused it to be undefined.
I had a similar problem. It was to do with a .a library, which should have been linked to my .so and statically linked into the archive being left out.
I determined this with (OP object name used here):
nm mylibrary.so | grep ZTVN10_cxxabiv117__class_type_infoE 0000ABC0 U ZTVN10_cxxabiv117__class_type_infoE The U here means that the symbol is «undefined». You can find the demangled name of the missing object with —demangle :
$ nm --demangle mylibrary.so | grep 0000ABC0 0000ABC0 U abi::class_type_info(params. ) (or something like that) this should help you figure out which library is missing.
In my case, even after including the library on the compiler line I still had the issue. Eventually, after some tinkering I discovered that the library-file ( .a ) has to come after its dependent object ( .o ) file like:
g++ -Wl,-E -g -m32 . -fPIC myobjects1.o myobjects2.o missing_library.a -shared -o mylibrary.so $ nm --demangle mylibrary.so | grep 0000ABC0 0000ABC0 T abi::class_type_info(params. ) and most importantly I don’t get the error any more!
dlopen — Undefined symbol error
In that shared object I refer to a const char* defined in another shared library «SharedLibarary2.so». The Executable, and both the libraries are built using -rdynamic. But I still get the run time error when using dlopen: «/usr/lib/SharedLibarary1.so: undefined symbol» and points to the mangled const char* has the undefined symbol. Whith GDB «info share» I can see that the second library is not loaded at the point of the error. How ever that problem goes away if I do a dlopen on the second library before I do on the first library. Is there a better way to force the loader to load the second library for the unresolved symbol?
yes. Don’t make the library you load rely on something that will only be linked in by another library that you will load using dlopen(). Use a shared object that is loaded the regular way that has that symbol. Does using RTLD_LAZY help by the way?
2 Answers 2
When building a shared library, you can link another inside, e.g. like
gcc -shared -rdynamic lib1*.pic.o -lshared2 -o SharedLibrary1.so Then check with ldd SharedLibrary1.so
(look e.g. at the output of ldd on your system’s libgtk-3.so.0 for an example)
% 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) symbol lookup error on C dynamic library
I’ve a problem that drive me crazy. I’ve an Ubuntu developer machine. I’ve downloaded a toolkit and I’ve included it into my C project (eclipse). Well, if I build the project using eclipse on a centos VM the resultant application, copied to the ubuntu system works well. On the centos machine the command make produce at any time a working application. If I copy the project, including the makefile, on the ubuntu machine and rebuild by means of make command (the makefile doesn’t change. ) the application built has a «symbol lookup error: . undefined symbol . » the function that is not found is ‘declared’ (but not implemented) into a library (included into the toolkit, not my production. ) and implemented into another library (always into the toolkit clearly). WHY. And Above all, how to fix? I should include also these dynamic libraries at linking time? (but the makefile is the same!) same makefile two differents OS, make doesn’t work tow differents OS, copied application and relevant libraries, it works Thanks a lot. one beer (in Bremen)to who makes me understand where I’m doing a . I add more details: cmd (same on ubuntu and centos):
gcc -L/home/andrea/put/lib -o "put" ./main.o -ltrek_toolkit_ds_api -ltrek_toolkit_common_api -ltrek_toolkit_cfdp_api -lcfdp_plus -lrt gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 [NOT WORKING] gcc (GCC) 4,8,3 20140911 (Red Hat 4,8,3-9) [WORKING] linux-vdso.so.1 => (0x00007ffd26b15000) libtrek_toolkit_ds_api.so.0 => not found libtrek_toolkit_common_api.so.0 => not found libtrek_toolkit_cfdp_api.so.0 => not found librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f23d29cb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f23d2606000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f23d23e8000) /lib64/ld-linux-x86-64.so.2 (0x00007f23d2bd3000) linux-vdso.so.1 => (0x00007fffdd569000) libtrek_toolkit_ds_api.so.0 => not found libtrek_toolkit_common_api.so.0 => not found libtrek_toolkit_cfdp_api.so.0 => not found libcfdp_plus.so.0 => not found /lib64/librt.so.1 (0x00007f158e0c9000) libc.so.6 => /lib64/libc.so.6 (0x00007f158dd08000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f158daec000) /lib64/ld-linux-x86-64.so.2 (0x00007f158e2fb000) gcc -L/home/andrea/put/lib -o "put" ./main.o -ltrek_toolkit_ds_api -ltrek_toolkit_common_api -ltrek_toolkit_cfdp_api -Wl,--whole-archive -lcfdp_plus -Wl,--no-whole-archive -lrt ./put: symbol lookup error: /home/andrea/put/lib/libtrek_cfdp_device_api.so: undefined symbol: register_printf_debug «register_printf_debug» is included in library cfdp_plus, that is included when built on centos and not when built on Ubuntu. So, how to tell to the linker to do its job and to include this library?