Native Plug-in Compatibility¶
Katana 3.5v2 and its third-party library dependencies are compiled with GCC 4.8.2 on Linux, and Visual Studio 2015 Update 3 on Windows.
In most cases this is an implementation detail. Katana has long separated its SDK into a set of C++ headers and sources compiled directly into plug-in code and a stable, compiler-agnostic C-based API that’s wrapped by the C++ layer. This separation allows a plug-in author writing a Geolib Op, for example, to build with their choice of toolchain.
On Windows, there are some exceptions. As Visual Studio does not guarantee a stable C++ ABI from release to release, plug-in authors building plug-ins that link against Qt are required build with Visual Studio 2015 Update 3.
We also recommend that Python C extension modules are built using Visual Studio 2015 Update to ensure it uses the same Visual Studio C Runtime (CRT) as the Python libraries shipped with Katana. As the default compiler for building Python 2.7 C extensions is Visual Studio 2008, it may be necessary to override distutils/setuptools’ choice of compiler when building an extension module. See distutils API Reference for further information.
Native Katana plug-ins are runtime-loaded using dlopen(3) and
RTLD_LOCAL. This ensures that dynamic symbols defined by your plug-in (or
its dependencies) are not used to resolve future symbol references from some
other shared object.
Katana’s executables use
RPATH entries to ensure our installation paths
are searched for dependencies first. Bear in mind that library search paths
RPATH are scanned ahead of paths specified in
Native Katana plug-ins are runtime-loaded using LoadLibraryEx() and the
LOAD_WITH_ALTERED_SEARCH_PATH flag. The use of this flag means the Windows
Loader will first consider the directory of the plug-in when searching for
libraries it depends on. For more information, see the MSDN article
Dynamic-Link Library Search Order.