How to build usd to allow for static linking

koen · December 19, 2024, 3:07pm

Hello all,
First, thanks for all that work on removing boost, building a “core” version of openusd feels so clean now, that will reduce the friction with sticking this in our build system by quite a bit!

Next,
I am trying to build usd so my applications can statically link to it instead of relying on the usd_ms.dll. I am looking at this document:

OpenUSD/BUILDING.md at release · PixarAnimationStudios/OpenUSD

and am trying the following build command based on this:
python build_scripts/build_usd.py --no-examples --no-tutorials --no-tools --no-python --no-imaging --no-usdview --no-materialx --cmake-build-args BUILD_SHARED_LIBS=OFF %INSTALL_DIR%

but this still gives me all the dll’s. What would be the correct flag to build_usd.py to just get the static libs?

Thanks,
Koen

dhruvgovil · December 19, 2024, 6:25pm

I might be wrong, but I believe you also need to enable monolithic builds too?

koen · December 19, 2024, 10:30pm

I’ll try that, thanks, I had taken that out, that’s out default build method. For now, I just hacked build_usd.py to pass build shared_libs off to see how far I get. I’m not sure I’ll be able to get tbb to static link. As long as I have a dll, I dont mind two

Cheers,
Koen

dhruvgovil · December 19, 2024, 10:34pm

I believe some of the changes I have in my framework build might be of interest

github.com/PixarAnimationStudios/OpenUSD

Apple: Enable building as an Apple Framework

PixarAnimationStudios:dev ← dgovil:ios_core_frameworks

opened 06:41PM - 26 Feb 24 UTC

dgovil

+609 -94

### Description of Change(s) This PR enables building of USD as a Framework. … A framework build puts the output files into a directory structure which allows them to be included easily in apps on macOS, iOS and visionOS. The steps to use it are included in the README but are repeated here in brief: 1. User drags the Framework directory into their project target. This automatically sets up linkage. 2. User sets it to Embed and Sign in the app Frameworks are enabled automatically for Apple embedded platforms (iOS, visionOS). Framework builds default to Monolithic because a framework may only include one dylib within it. Shared builds can still be enabled for some dev purposes, but aren't officially supported. **Experimental Feature** I request that the feature be marked as Experimental in the README, because I anticipate changes might be needed in the future to streamline how this works, such as not requiring the dependencies to be statically built. I think the current state of the PR will unblock the majority of people asking for this feature however and the changes I anticipate might be quite long term. This incorporates initial work by Maddy Adams and @meshula . The changes are largely non-invasive and are listed below: **Core Code Changes** 1. Adds a post build step with a zsh script that will construct the Framework bundle. 2. Changes to the Plugin and usdMtlx registry to find their respective resources within the Framework 3. Enable building statically against TBB and OpenSubdiv. 4. New options in the CMake to handle framework build configuration **Build Script Changes** 1. Added argument to build as Framework (or disable) with `--build-apple-framework` and `--no-build-apple-framework` 2. Added support to `apple_utils.py` to orchestrate an `XCFramework` build, that combines multiple targets into one framework. 3. Added support for Simulator targets 4. Allow shared/monolithic builds arg to allow a default based on other args. 5. Build Dependencies (MaterialX, TBB) as static when building monolithic 6. Allow users to pass in code signing ID manually 7. Improved Codesigning identity lookup speeds+reliability for both framework and non-framework builds 8. Setup signing for dependencies automatically when using Xcode target **Header Notes** Framework headers are automatically discovered when prefixed by the framework name. E.g instead of `#include <pxr/pxr.h>` you would do `#include <OpenUSD/pxr/pxr.h>` If someone wants to avoid the prefixed behavior, they have to manually add the Header directory to their targets `SYSTEM_HEADER_SEARCH_PATHS` . - [X] I have verified that all unit tests pass with the proposed changes - [X] I have submitted a signed Contributor License Agreement

It targets Apple platforms of course, but I changed how the shared/monolithic builds get passed in to build_usd.py, and also changed how TBB + other dependencies get statically built.

mmarkd8 · December 26, 2024, 2:42pm

Sorry for interjecting but did anyone succeed in having a static build without the normal plugin search?

I’m building static libraries (either monolithic or single static libraries it doesn’t seem to matter) but I’m still getting failures by the unbuilt plugins (and why is it searching for plugins at all?)

see Cannot find plugins even in static build?

dhruvgovil · December 26, 2024, 4:12pm

You’ll need the plugin search to still look for the plugInfo.json to find what to register. See my PR above.

The JSON files still include various metadata about how each plugin is used, which is why they can’t simply be elided.

However I think it might be worth having a setup where static or monolithic builds pull the JSON data as internalized static data.

Topic		Replies	Views
Build latest USD with onetbb USD	1	77	July 19, 2024
Error building USD Build and Deployment	1	163	March 19, 2024
Advice on portable USD build artifacts Build and Deployment	4	190	July 1, 2024
Decrease rebuilds of plug-ins between USD versions Build and Deployment	2	96	July 1, 2024
Compiling OpenUSD with clang, and libc++.so Build and Deployment	0	55	September 9, 2024

How to build usd to allow for static linking

Related topics