我有一个动态库，它通过链接到libgsoapssl ++提供了onvif服务。gsoap是一个静态库，我已经用-fPIC重新编译了它。
然后，我将此动态库链接到使用其服务的可执行文件。当我运行此可执行文件时，我得到：
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的更好替代方案，我将不胜感激。
答案 0 :(得分：0)
感谢Mike Kinghan指出我应该看到的内容。
这里的问题是/ usr / lib中共享库的旧版本，当我将LD_LIBRARY_PATH更改为指向特定于项目的lib目录后，该旧版本仍然存在。删除/ usr / lib中的库可以解决当前的问题，并导致可以访问正确的库实例。