Download
http://github.com/imageworks/OpenColorIO/tarball/master
cd /tmp and unpack the tarball to create /tmp/imageworks-OpenColorIO-a557a85
mkdir /tmp/build
cd /tmp/build
ccmake /tmp/imageworks-OpenColorIO-a557a85
Edit the config to manually specify the include folder for Nuke 10.0.1 (in 'advanced mode' search for Nuke_INCLUDE_DIR and set it to be /path/to/nuke/include
and Nuke_LIBRARIES to /path/to/nuke)
turn off OCIO_BUILD_SHARED
set CMAKE_MODULE_FLAGS, CMAKE_LINKER_FLAGS and CMAKE_EXE_FLAGS to "-L /tmp/build/src/core"
make
copy the nodes from /tmp/build/src/nuke/*.so to ~/.nuke/
Start nuke
Try to read an EXR - you get the same backtrace we get from out internal nodes.
If you repeat the process with Nuke_INCLUDE_DIR pointing to Nuke 9.0v8 there's no error from the EXR read. I recall some change in Nuke 10 about OCIO support in read nodes and suspect this may be related to the crash.
There is also a crash with OCIO_BUILD_SHARED on, but that might be an unrelated build issue, and Weta statically links to OpenColorIO.
If you simply view ColorBars with OCIO Viewer process LUTs enabled, and don't load any images, there's no error, but the display is monochrome, in both 9 and 10.
Apparently the Foundry internal OCIODisplay node's channel_selector knob has entries in a different order in Nuke 9 onwards. We modified our internal version to work around that.
Reproduced by support
Engineering reproduced
Expected behaviour
no crash and access to variables
Actual behaviour
crash