i有一个动态库，它通过链接到libgsoapssl 提供了ONVIF服务。我从GSOAP的静态库，我已经使用-fpic重新编译了
。i然后将此动态库链接到使用其服务的可执行文件。当我运行此可执行文件时，我会得到：
symbol lookup error: /usr/lib/libonvif.so: undefined symbol: soap_base64o
该符号似乎是在动态库中定义的，如NM：
所示nm libonvif.so | grep soap_base64
00000000008cec40 T soap_base642s
0000000000914b60 R soap_base64i
0000000000914bc0 R soap_base64o
可执行文件(ONVIFCL(似乎正确地取决于静态库(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)
我不知所措，为什么符号不确定。有人知道我在这里缺少什么吗？
顺便说一句，在为我要解决的实际问题开发潜在的解决方法时，已经发生了这个问题。我正在尝试使用boost.python包装动态库的类，以便我可以从Python3访问它。这样做只有在访问GSOAP定义的结构或方法时才会导致分割故障，这使我考虑未解决的参考。将GSOAP库汇总到共享库中可能会解决该问题，但是我找不到太多关于如何做到的问题。如果有人在这方面有任何想法，或者是Boost.python的更好替代方案，我将不胜感激。
感谢迈克·金汉(Mike Kinghan(指出了我应该看到的内容。
这里的问题是/usr/lib中共享库的旧版本，它在我更改ld_library_path以指向特定于项目的lib目录之后。删除/usr/lib中的库解决了直接问题并导致访问正确的库实例。