1

I am compiling a plugin for Nuke8 under linux. All compiling is done without issue but i have the following error when i try to load the plug : 

undefined symbol: _ZN9Imath_2_16Rand325nextfEv

When i do "ldd" onto the plugin.so, i have this:

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

All lib seem to be load ok. I have a "libDDImage.so => not found", but this ok i have the same thing when i do this on exemple plugin.

I think the problem come from the Imath lib, but i don't know how to fix it. Anybody have an idea? Thanks in advance.

Best

jujut
  • 11
  • 1
  • 1
    `c++filt` reports the symbol to be `Imath_2_1::Rand32::nextf()`. – jxh Aug 07 '14 at 21:25
  • thanks for your replysorry but i don't understand what does it mean? – jujut Aug 07 '14 at 23:37
  • Maybe your issue is the order you list your shared libraries when you link your plugin. Can you try listing `-lImath` last? – jxh Aug 08 '14 at 00:01
  • it's what i do. It's possible that this kind of problem come from the compiler? i use gcc4.4 but it's recommend to use gcc4.1 for compiling stuff for nuke 8. – jujut Aug 08 '14 at 08:52

1 Answers1

1

UPDATE

Since this answer was originally posted, The Foundry have made their modified OpenEXR source code available for download, including the custom namespace and some interface extensions. This should make it easy to write and successfully build custom plugins that link against the distributed OpenEXR libraries.

Links to compiled bonaries and source files can be found at: https://www.thefoundry.co.uk/products/nuke/developers/

They also have an open pull request for these changes to be merged into the main OpenEXR project, which can be found here: https://github.com/openexr/openexr/pull/141

Original Answer

Unfortunately this type of issue is hard to nail down without knowing everything about your build and runtime environment, but here's some information and ideas that will hopefully help put you on the right track.

To summarize, I think it's likely one of four things:

  • Symbol namespace issue
  • Binary compatibility issue (due to the library version mismatch)
  • Library load issue
  • Compiler version issue

Symbol Namespaces

Nuke 8 ships with its own EXR 2 libraries (specifically, version 2.0.1), which you can find in the installation directory. If you look at the exported symbols (using nm -D), you can see that not only are the symbols in a custom namespace, but the library version is different than the one you are linking against.

$ 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()

As you can see, the EXR 2 symbols in Nuke are in the namespace Imath_2_0_1_Foundry, while your library is looking for the Imath_2_1 namespace. This would seem to indicate a library loading issue (either due to it not being found, or to Nuke not being able to load it).

Library Loading

Something that's always important to keep in mind is that the libraries that are resolved by ldd aren't necessarily going to be the same ones Nuke finds. The easiest way to examine what actually happens in Nuke is to run it through strace using something like the this:

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

Note that you may need to use the full path to the Nuke binary, depending on your shell environment. You should try and start Nuke with no other custom code running (other than whatever is required to get your plugin onto the plugin path), and without opening any Nuke scripts, in order to prevent anything else from loading the Imath library.

Once you have your empty Nuke session running, just attempt to create an instance of your node and then quit Nuke. Now you can grep through nuke_strace_output.txt and find the point where your plugin is loaded, which should look something like this: 

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

After that, if you scroll through the strace output, you'll see what steps Nuke takes when it tries to load the libraries your plugin depends on that have not yet been loaded (which names it tries, where it looks, etc.), which should include libImath (and I'm guessing libfftw3f).

Binary Compatibility

If possible, I would recommend trying to use the same version of OpenEXR that Nuke ships with, so you can just piggy-back on its libraries. You'll need to get your own headers in order to compile your plugin, but that's trivial for something like Imath.

As far as compilers go, you should be using GCC 4.1.2. If you don't, you're very likely going to run into binary compatibility issues at some point.

Anyway, I know this is jumping around into a lot of different areas, but I hope it helps some.

nrusch
  • 253
  • 2
  • 3