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) 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!
Receive «undefined symbol» error when loading library with dlopen
I’m writing some code that uses dynamic shared libraries as plugins. My command line for building the shared libraries looks like:
cc -shared -fPIC -o module.so -g -Wall module.c Within the module, I can call functions that are in any other shared library that has been loaded within the main executable. However I cannot access (exported) functions that are in the executable itself (I get undefined symbol errors). My call to dlopen looks like this:
void *handle = dlopen(plugin, RTLD_NOW); Can anyone please advise how my module can call back to my executable, without having to put all of the executable’s utility functions into yet another shared library?
3 Answers 3
Correct solution is to add -rdynamic to the link command of the main executable. This will add appropriate option to ld (which, when using GNU ld , happens to be —export-dynamic ).
Adding —export-dynamic directly is technically incorrect: it’s a linker option, and so should be added as -Wl,—export-dynamic , or -Wl,-E . This is also less portable than -rdynamic (other linkers have an equivalent, but the option itself is different).
This solution also applies when using Boost Extensions as boost shared_library class is using dlopen (on Linux) to load library.
I’ve found the answer myself.
I had to add the —export-dynamic flags to the link options for the main executable.
When creating a dynamically linked executable, add all symbols to the dynamic symbol table. The dynamic symbol table is the set of symbols which are visible from dynamic objects at run time.
If you do not use this option, the dynamic symbol table will normally contain only those symbols which are referenced by some dynamic object mentioned in the link.
If you use «dlopen» to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself.
undefined reference to symbol even when nm indicates that this symbol is present in the shared library
This is happening on Ubuntu 12.04. The libmnl-dev and libmnl0 packages are installed. The strace output of gcc indicates that ld is using exactly that *.so file:
[pid 10988] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/libmnl.so", 0x7fff2a39b470) = -1 ENOENT (No such file or directory) [pid 10988] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/libmnl.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 10988] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/libmnl.a", 0x7fff2a39b4d0) = -1 ENOENT (No such file or directory) [pid 10988] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/libmnl.a", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 10988] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libmnl.so", 0x7fff2a39b470) = -1 ENOENT (No such file or directory) [pid 10988] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libmnl.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 10988] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libmnl.a", 0x7fff2a39b4d0) = -1 ENOENT (No such file or directory) [pid 10988] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libmnl.a", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 10988] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libmnl.so", ) = 0 [pid 10988] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libmnl.so", O_RDONLY) = 7