Linux

An example CMakeLists.txt is included with the NDK examples shipped in the NDK sub-directory of the Documentation installed with NUKE. CMake is a preferred way of building plugins, the use of other build systems may not produce compatible plugins.

For Nuke 14.x, plug-ins compiled with GCC versions 9.3 through 9.5 should be compatible. Make sure that the macro _GLIBCXX_USE_CXX11_ABI is not defined or set to 0.

For Nuke 15.x, use GCC 11.2.1 or compatible and enable _GLIBCXX_USE_CXX11_ABI=1 compiler macro, if your toolchain doesn’t have that implicitly already.

Please refer to GCC’s ABI Policy and Guidelines. If your preferred Linux distribution makes use of patched GCC libraries, please consult the applicable compatibility notes of your distribution.

libc++, the C++ standard library implementation of the LLVM project, is not binary compatible with libstdc++, the C++ standard library implementation of GCC. Our plug-in interfaces only support objects that are created via libstdc++ (associated with the above GCC compiler version range). While untested and unsupported by The Foundry, using the clang compiler and linking against libstdc++ instead of libc++, targeted at C++17, may produce working plug-ins.

The use of Intel compilers for plug-in development is untested and unsupported. If you want to build with the Intel compiler, you may substitute it for g++. However you must make sure you use the libstdc++ includes and libs from a compatible GCC version, as outlined above, in order to be compatible.

We are using the C++17 standard, and it is advised to use the same standard for plugin builds to avoid any potential standard library and binary compatibility problems. To this effect please use the ‘-std=c++17’ compiler switch.

On Linux, NUKE 14.x is built on a Centos 7.4 Linux 64-bit machine, using GCC 9.3.1. We ship and link against a GCC 9.3.1 standard library at runtime. We are using the devtoolset-9 package to set up our development environment.

NUKE 15.x is built on a RockyLinux 8.6 Linux 64-bit machine, using GCC 11.2.1. We ship and link against a GCC 11.2.1 standard library at runtime. We are using the gcctoolset-11 package to set up our development environment.

The shared object files (.so) resulting from a plug-in build should either be placed in your ~/.nuke directory, or a location in your NUKE plug-in path, in order to be loaded into NUKE.

See Building & Installing Plug-ins for information on creating your first plug-in.

ABI issues

Due to the switch in GCC CXX ABI in VFX Reference Platform, Nuke 15.0 and 14.1 plugins must be built with different compiler macro value for _GLIBCXX_USE_CXX11_ABI. Binaries built with this macro set to 0 are not binary compatible with binaries that are built with _GLIBCXX_USE_CXX11_ABI=1. Typical error message of trying to load a plugin built with the wrong ABI setting looks like this:

` /path/to/plugin.so: undefined symbol: _ZNK2DD5Image2Op15input_longlabelEi `

and when looking for the symbol in libDDImage.so, we’ll find the following:

` $ Nuke15.0v1-Beta.2 nm -C libDDImage.so|grep input_longlabel DD::Image::Op::input_longlabel[abi:cxx11](int) const `

The above means that the plugin was built with _GLIBCXX_USE_CXX11_ABI=0, and emitted a the symbol DD::Image::Op::input_longlabel(int) const, while Nuke is built with _GLIBCXX_USE_CXX11_ABI=1. The opposite case is looks similar, except that Nuke 14.x doesn’t have [abi:cxx11] tag in the function signature, while the plugin does.