C++ 未定义的核弹符号：_ZN9Imath_2_16Rand325nextfEv

我正在为linux下的Nuke8编译一个插件。所有编译都顺利完成，但在尝试加载插件时出现以下错误：

undefined symbol: _ZN9Imath_2_16Rand325nextfEv

当我在插件上执行“ldd”时，我有：

linux-vdso.so.1 =>  (0x00007fff44869000)
libDDImage.so => not found
libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x00007f4609bf5000)
libImath.so.6 => /usr/lib64/libImath.so.6 (0x00007f46099f0000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f46096ea000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4609465000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f460924f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4608ebb000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4608c9d000)
libIex.so.6 => /usr/lib64/libIex.so.6 (0x00007f4608a7f000)
/lib64/ld-linux-x86-64.so.2 (0x000000300bc00000

所有库似乎都加载正常。我有一个“libDDImage.so=>not found”，但这个ok我有同样的东西，当我在Example插件上这样做的时候

我认为问题来自Imath库，但我不知道如何解决它。 有人有主意吗？提前谢谢

最佳更新 由于这个答案最初是发布的，Foundry已经提供了修改后的OpenEXR源代码供下载，包括自定义名称空间和一些接口扩展。这将使编写和成功构建链接到分布式OpenEXR库的自定义插件变得容易

可在以下位置找到已编译的bonaries和源文件的链接：

他们还请求将这些更改合并到主OpenEXR项目中，可以在以下位置找到：

原始答案 不幸的是，在不了解构建和运行时环境的所有信息的情况下，很难解决这类问题，但这里的一些信息和想法有望帮助您走上正确的道路

总而言之，我认为这可能是四件事之一：

• 符号命名空间问题
• 二进制兼容性问题（由于库版本不匹配）
• 库加载问题
• 编译器版本问题

符号名称空间 Nuke 8附带了自己的EXR 2库（特别是2.0.1版），可以在安装目录中找到。如果查看导出的符号（使用

nm-D

），您不仅可以看到自定义名称空间中的符号，而且库版本与您正在链接的版本不同

$ nm -D "/usr/local/Nuke8.0v5/libImath-2_0_1_Foundry.so.10" | grep Rand | c++filt
0000000000012590 T Imath_2_0_1_Foundry::Rand32::nextf()

如您所见，Nuke中的EXR 2符号位于命名空间

Imath_2_0_1_Foundry

，而您的库正在查找

Imath_2_1

命名空间。这似乎表明存在库加载问题（要么是因为找不到它，要么是因为Nuke无法加载它）

库加载 需要始终牢记的一点是，

ldd

解析的库不一定与Nuke找到的库相同。检查核武器中实际发生的情况最简单的方法是通过

strace

使用如下方式运行：

$ strace -fqo /var/tmp/nuke_strace_output.txt Nuke

请注意，您可能需要使用

Nuke

二进制文件的完整路径，具体取决于您的shell环境。您应该尝试在不运行其他自定义代码的情况下启动Nuke（将插件放到插件路径所需的代码除外），并且不打开任何Nuke脚本，以防止加载

Imath

库中的任何其他内容

运行空的Nuke会话后，只需尝试创建节点的实例，然后退出Nuke。现在，您可以通过

nuke\u strace\u output.txt
grep
找到插件的加载点，该点应如下所示：

open("/path/to/MyPlugin.so", O_RDONLY|O_CLOEXEC) = 50

之后，如果您滚动查看
strace
输出，您将看到Nuke在尝试加载插件所依赖的库时所采取的步骤，这些库尚未加载（它尝试的名称、外观等），其中应包括
libImath
（我猜
libfftw3f
）

二进制兼容性
如果可能的话，我建议您尝试使用Nuke附带的同一版本的OpenEXR，这样您就可以利用它的库了。为了编译插件，您需要获得自己的头文件，但对于Imath之类的东西来说，这是微不足道的

就编译器而言，您应该使用GCC4.1.2。如果不这样做，您很可能会在某个时候遇到二进制兼容性问题

无论如何，我知道这涉及到很多不同的领域，但我希望它能有所帮助。
c++filt
报告符号为
Imath_2_1:：Rand32:：nextf（）
。谢谢你的回复，抱歉，但我不明白这意味着什么？也许你的问题是链接插件时列出共享库的顺序。你能试着最后列出
-climath
吗？我就是这么做的。这类问题可能来自编译器？我使用gcc4.4，但建议使用gcc4.1来编译nuke 8的资料。更新的答案包括到铸造厂OpenEXR源代码修改的链接