Why do I get an undefined symbol when linking shared library that links static (gSoap) library?

Question

I have a dynamic library that provides onvif services by linking to the libgsoapssl++.a static library from gsoap, which I have recompiled with -fPIC.

I then link this dynamic library to an executable that uses its services. When I run this executable I get:

symbol lookup error: /usr/lib/libonvif.so: undefined symbol: soap_base64o

The symbol appears to be defined in the dynamic library as shown by nm:

nm libonvif.so | grep soap_base64

00000000008cec40 T soap_base642s
0000000000914b60 R soap_base64i
0000000000914bc0 R soap_base64o

The executable (onvifcl) appears to be correctly dependent on the static library (libonvif.so):

ldd onvifcl 

linux-vdso.so.1 (0x00007ffe623f6000)
libonvif.so => /usr/lib/libonvif.so (0x00007f4e09b86000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4e097fd000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4e095e5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4e091f4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4e08e56000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4e0aa54000)

I'm at a loss as to why the symbol is undefined. Does anyone know what I'm missing here?

As an aside, this problem has occurred while developing a potential workaround to the actual problem I'm trying to solve. I'm trying to use boost.python to wrap the classes of the dynamic library so I can access it from Python3. Doing so caused segmentation faults only when accessing gsoap defined structures or methods, which led me to consider unresolved references. Compiling the gsoap library into a shared library might fix that problem but I can't find much on how to do that. If anyone has any ideas on that front, or a better alternative to boost.python, I'd appreciate it.

Answer 1

Thanks to Mike Kinghan for pointing out what I should have seen.

The issue here was an old version of the shared library in /usr/lib that remained after I changed LD_LIBRARY_PATH to point to a project-specific lib directory. Deleting the library in /usr/lib resolved the immediate problem and caused the correct library instance to be accessed.