Cannot find plugins even in static build?

Community Build and Deployment
1

Hello everyone, I’ve been attempting a OpenUSD C++ static libraries build and confirmed that my C++ unix executable no longer depends on other OpenUSD .so libraries.

I used

python build_scripts/build_usd.py --no-python --usd-imaging --no-usdview --no-materialx --build-args=USD,"-DBUILD_SHARED_LIBS=OFF -DPXR_BUILD_MONOLITHIC=OFF" ./build

I am still getting plugin resolver issues though:

$ build/myusdprogram
Will check plugin info paths:
    
 Did check plugin info paths in 0.000001 seconds
Coding Error: in _GetPluginForType at line 163 of /home/usergfp/OpenUSD/pxr/usd/ar/resolver.cpp -- Failed to find plugin for ArDefaultResolver
Segmentation fault (core dumped)

I included the libusd_ar.a library for linking, how come I’m still getting this error about missing plugins?

Docs say

Static Libraries

This mode builds several static libraries. This option allows embedding just the libraries necessary for a given task. However, it does not allow USD plugins or Python modules since that would necessarily cause multiple symbol definitions; for any given symbol we’d have an instance in the main application and another in each plugin/module.

Doesn’t this mean that plugins should be embedded on a as-needed basis and no longer required to be searched for in paths?

Thanks for any help!

2

Even though the symbols for the plugins are included statically, the registration system still requires searching for the plugInfo.json that define the capabilities of the plugins and other metadata.

You’ll need to configure your plugin search path to locate them.

3

Thanks for the help Dhruv!

Making a full static build is currently really not easy and as you noted it requires the plugin folders as well for plugInfo.json / autogenerated schemas and other stuff.

I guess there could be value in having some flag in build_usd.py to link everything statically (zero-deps all-included) and having plugins info statically embedded/linked at compile-time somehow as you suggested here How to build usd to allow for static linking - #6 by dhruvgovil

4

Hello @mmarkd8 ,

Out of curiosity, do you statically link tbb as well or is that still a dso?

Thanks,
Koen

5

Hey koen!

python build_scripts/build_usd.py --no-examples --no-tutorials --no-python --usd-imaging --no-usdview --no-materialx --build-monolithic --build-args=TBB,"extra_inc=big_iron.inc"

this builds TBB as a static library as well. I managed to get a full-static build (i.e. no deps, all integrated) but the plugin system still wants those json and additional schema/plugin files expecting them in the same filesystem hierarchy, so you can’t really (yet) ship a single executable with full OpenUSD capabilities.

As Dhruv noted that’d be nice to have.

6

Thanks! And yes, fully static including even the plugin definitions would be great. Since we don’t distribute, I’m able to just add a single extra location to the usd code ( this is the single patch I have at the moment).

Will try this command line.

Cheers,
Koen

7

Just to understand: are you saying that you have a patch to ‘uncompress’ or ‘de-embed’ all of the plugin directories from a single executable? Or maybe a way to register that data directly from code?

If so I’d be very interested - the single executable all-contained is rather appealing to me

8

Oh no sorry, nothing as useful as that. All I do is add a few lines to allow usd to find the plugin.json through our internal config system ( we don’t really have a great way to deal with environment variables ). The plugin folder still exists as is, just in another spot.

Having the default setup embedded in the exe would be very nice indeed.