Working with Third-party Libraries

Katana has many dependencies on third-party libraries – these are documented in the “External Software” appendix in the Katana Online Help.

Wherever possible, these dependencies are kept internal to the Katana application and do not “leak out” into plug-in code, and as such you should be able to link against your own version of those libraries in your plug-ins. We achieve this using a mix of static linking, restricted symbol visibility (on Linux), and using Foundry-specific namespaces and library names for some libraries.

In some cases, however, this was not possible. For example, you should not attempt to link your plug-in against versions of Python, Qt or PyQt other than the version used by Katana.

If you do experience compatibility problems, please do report them to our support team, as we’re always looking for ways to improve the product.

Note

Switching out libraries Katana depends on with your own is something that should be done with care, as it makes your Katana installation harder for us to support. Wherever possible, you should consider static linking, namespacing or other methods of symbol versioning so that Katana and your plug-in can run different versions of the libraries they depend on.

Linux Specific Notes

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.

Note

Katana executables use RPATH entries to ensure our installation paths are searched for dependencies first. Bear in mind that library search paths specified in RPATH are scanned ahead of paths specified in LD_LIBRARY_PATH. So if you do feel it necessary to experiment with other ABI (and behaviourally) compatible libraries, your only recourse would be to delete libraries we ship, or to overwrite them.

Windows Specific Notes

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.