dynamic library loading : easy way to figure out unresolved symbols runtime

Question

I am working on a huge project which is loading dynamic libraries at runtime using ACE_DLL::open.

Library is located and tries to open but fails on mmap ( below is the strace ) because of unresolved symbols. I know for sure that its because of unresolved symbols and by running nm I could get the list of all unresolved symbols. Problem is there are tons of unresolved symbols at compile time which should in turn be resolved at run time, so nm is not very helpful as I need to go through all symbols one by one.

Is there a smart way to figure out exact what is causing the .so to be loaded

open("libxxxxxxx_d.so", O_RDONLY) = 29
read(29, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300w\3\0004\0\0\0"..., 512) = 512
fstat64(29, {st_mode=S_IFREG|0755, st_size=10130306, ...}) = 0
mmap2(NULL, 373832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 29, 0) = 0xffffffffed5f5000
mmap2(0xed64e000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 29, 0x59)  =   0xffffffffed64e000
close(29)                               = 0
munmap(0xed5f5000, 373832)              = 0
munmap(0xed5cc000, 167764)              = 0

Answer 1

Set ACE_DEBUG=1 as environment variable, the ACE logging should than print a debug message indicating which symbol is unresolved. This is just one symbol, so you probably need several iterations to find all

Answer 2

The strace fragment does not show any kind of failure. The open of the shared library appears to have been successful.

I am not familiar with the ACE_DLL::open which you mention, but I found some information here and it looks like it is just a thin wrapper around dlopen() and friends.

Now it is possible that the library fails to open due to unresolved symbols at dlopen() but only if RTLD_NOW is used. The problem is that the error message mentions only one problematic symbol.

If you don't want to traverse the list of symbols that the library requires with nm or objdump -T or similar, the easiest thing you can probably do is link your application against the library in question and see what the linker reports as errors. It should list all of the problems instead of just one. First, add some placeholder code to your application that will reference any valid symbol from the library (to force the library to be pulled in by the linker), and then add -lxxxxxxx_d to your link oprions.

Answer 3

This command will report any missing functions and objects in a shared library:

ldd -r your_library.so

See man ldd for more info.