I created an OpenFX plugin (dynamic library) that internally uses OpenUSD 24.11, and I want to load it as a plugin in Nuke 15. Nuke also uses OpenUSD (probably not version 24.11), and when it tries to load my plugin it prints these errors:
Error: The metadata for plugin 'usdImaging' defined in c:/Users/pedro/.conan2/p/b/openu7eedc43059794/p/bin/usd_usdImaging.dll declares type 'UsdImagingDrawModeAdapter' with base type 'UsdImagingInstanceablePrimAdapter', but the type has already been declared with a different set of bases that does not include that type. The existing bases are: (UsdImagingPrimAdapter ). Please fix the plugin.
Error: The metadata for plugin 'usdImaging' defined in c:/Users/pedro/.conan2/p/b/openu7eedc43059794/p/bin/usd_usdImaging.dll declares type 'UsdImagingLightAdapter' with base type 'UsdImagingInstanceablePrimAdapter', but the type has already been declared with a different set of bases that does not include that type. The existing bases are: (UsdImagingPrimAdapter ). Please fix the plugin.
Error: The metadata for plugin 'usdImaging' defined in c:/Users/pedro/.conan2/p/b/openu7eedc43059794/p/bin/usd_usdImaging.dll declares type 'UsdImagingPointInstancerAdapter' with base type 'UsdImagingInstanceablePrimAdapter', but the type has already been declared with a different set of bases that does not include that type. The existing bases are: (UsdImagingPrimAdapter ). Please fix the plugin.
Error: Failed to load plugin 'usd': The specified procedure could not be found.
in 'c:/Users/pedro/.conan2/p/b/openu7eedc43059794/p/bin/usd_usd.dll'
Error: Failed to load plugin 'usd': The specified procedure could not be found.
in 'c:/Users/pedro/.conan2/p/b/openu7eedc43059794/p/bin/usd_usd.dll'
Error: Failed to load plugin usd for Usd_UsdzResolver
Error: Failed to load plugin 'usdHydra': The specified procedure could not be found.
in 'c:/Users/pedro/.conan2/p/b/openu7eedc43059794/p/bin/usd_usdHydra.dll'
Error: Failed verification: ' pluginFactory '
Error: Failed to find plugin for schema type 'UsdRenderDenoisePass'
Error: Failed to find plugin for schema type 'UsdRenderDenoisePass'
Error: Failed to load plugin 'hgiGL': The specified procedure could not be found.
in 'c:/Users/pedro/.conan2/p/b/openu7eedc43059794/p/bin/usd_hgiGL.dll'
Error: [PluginLoad] PlugPlugin could not be loaded for TfType 'HgiGL'
It appears that Nuke’s OpenUSD is statically linked. What can I do to let Nuke and my library coexist in the same process? Downgrading to Nuke’s version of OpenUSD won’t help because other versions of Nuke or other software could use a different version of OpenUSD anyway. I just need my library to run OpenUSD without interfering with Nuke’s own OpenUSD.
Can any of the following approaches help?
Link my library against OpenUSD statically
Build OpenUSD in a custom namespace my_pxr:: (I think there’s an OpenUSD build option for this)
the safest would be to namespace yours, and not deal with potential run time problems.
##### C++ Namespace Configuration
USD comes with options to enable and customize C++ namespaces via the following
flags:
| Option Name | Description | Default |
| ------------------------------ |-----------------------------------------| ------- |
| PXR_SET_EXTERNAL_NAMESPACE | The outer namespace identifier | `pxr` |
| PXR_SET_INTERNAL_NAMESPACE | The internal namespace identifier | `pxrInternal_v_x_y` (for version x.y.z) |
| PXR_ENABLE_NAMESPACES | Enable namespaces | `ON` |
Just to clarify, Nuke doesn’t link USD statically. It has a bridge library that sits between Nuke and USD allowing users to replace Nuke’s USD with their own. This library links USD dynamically. Since the USD can be changed by users, you can’t make any assumptions about the USD version other than it being at least Nuke’s base USD version (currently on USD 24.05 but we’ll be moving to a newer version soon). Loading two dynamic versions of USD will result in the errors you’re seeing unless one is namespaced.
Here’s a breakdown of the problems I found and how I fixed them:
PXR_PLUGINPATH_NAME environment variable was set to the installation path of my OpenUSD build, so Nuke would try to load plugins from it at startup and fail to do so (hence the error messages). To fix this, I just cleared the environment variable
Nuke’s OpenUSD DLLs had the same names as the ones in my OpenUSD build, so my plugin would get linked against Nuke’s DLLs instead of mine (at runtime), and the linking would fail because the symbols don’t match. To fix this, I used PXR_LIB_PREFIX to build DLLs with different names. Some plugin DLLs (e.g. hdStorm.dll) are unaffected by PXR_LIB_PREFIX so they still have the same names between Nuke’s build and mine, but somehow it works. I’d like to understand how this is possible as I’m afraid I’m misunderstanding something important but the fact is that it works.
Just wanted to note that a USD build’s “plugin path env var name” can be changed, during the build, to something other than PXR_PLUGINPATH_NAME, if you do expect “your” USD to be used alongside someone else’s in a configured environment.
Clashing library names can be a real problem. We had a big problem with MaterialX on Mac because something at startup was loading WebKit, which was loading SceneKit, which was loading macOS’s own copy of USD, which was loading MaterialX. The macOS system MaterialX libraries had the same library names as our own, causing symbols to be randomly loaded from either of the two libraries, followed by crashes. This doesn’t happen any more so it seems that the names have been changed (I like to think because I reported the problem).