Accessing .so libraries using dlopen() throws undefined symbol error

Question

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 )
  {
     printf( "Could not open file : %s\n", dlerror() );   
     return 1;
  }

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?

score 20 · Accepted Answer · answered Jan 31 '13 at 10:52

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.

score 11 · Answer 2 · answered Jan 31 '13 at 10:48

11

The ldd command can be used to display shared library dependencies.

ldd libCamera.so

Once you know the dependencies, you can use nm to show the symbols in each library.

nm -DC libCamera.so

answered Jan 31 '13 at 10:48

Austin Phillips

15,228
2
51
50

1

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. – Charles L. Oct 23 '14 at 00:56

robert · Answer 3 · 2016-12-22T09:51:03.103

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

Now I get (no more U):

 $ nm --demangle mylibrary.so | grep 0000ABC0 
0000ABC0 T abi::class_type_info(params...)

and most importantly I don't get the error any more!

score 1 · Answer 4 · answered Jun 22 '13 at 09:36

1

In your source code for libCamera.so, you have unresolved external symbol. It means that type_infoE have no definition in your source code and should be resolved.

answered Jun 22 '13 at 09:36

A23149577

2,045
2
40
74

Accessing .so libraries using dlopen() throws undefined symbol error

4 Answers4

Linked