Optimized build on Windows fails to load plugins

[mistafunk]

Description of Issue

Optimized ("release") builds on Windows fails to load plugins

Workaround:

• Build USD with -Zc:inline- instead of -Zc:inline

Steps to Reproduce

1. Build 19.11 on Windows with MSVC 14.23 (Visual Studio 2019) in release mode
2. In a client app, call pxr::PlugRegistry::GetInstance().GetAllPlugins().
3. Bug: returned list is empty.

System Information (OS, Hardware)

• Windows 10
• Intel i7-7700K

Package Versions

• USD 19.11
• MSVC 14.23

Build Flags

-DBUILD_SHARED_LIBS=1
-DPXR_BUILD_MONOLITHIC=1
-DPXR_ENABLE_PYTHON_SUPPORT=0
-DPXR_BUILD_IMAGING=0
-DPXR_BUILD_TESTS=0
-DCMAKE_BUILD_TYPE=Release

[mistafunk]

The Microsoft documentation for "Zc:inline" basically tells us that the USD sources are "non-conformant with C++11" and need an update: https://docs.microsoft.com/en-us/cpp/build/reference/zc-inline-remove-unreferenced-comdat?view=vs-2019

[c64kernal]

Thanks again for filing, @mistafunk -- for future reference, here is the usd-interest link for the original thread, so we can find it easily later: https://groups.google.com/forum/#!topic/usd-interest/s0l7TR-j-Qg

As for this problem, it's interesting. We don't actually declare Plug_InitConfig as "inline" I don't think. Our code base, for better or for worse, does rely on being able to call these kinds of functions on dll load or startup, they're wrapped in ARCH_CONSTRUCTOR and a lot of our registry mechanisms are built around it.

We don't use Windows in production and tend to lag on Windows support, but if you or anyone has suggestions on what the best way to handle this is, we'd love to hear them. Thanks again for the report!

[meshula]

It's definitely an optimization bug on Microsoft's part. The problem isn't non-conformant code, it's this catch-all subclass of entities:

Removes unreferenced functions or data that are COMDATs or only have internal linkage.

It's the "only have internal linkage" that's messing things up. It seems the msvc is unable to notice that the static global initialization in the plugins have non-local side effects. Pioneers building USD on iOS and Android are encountering the same issue. I have fixed this in custom builds in the past by exporting the static initialization functions in the plugins, so that the compiler/linker understands that they can't be dead-stripped. It's possible to achieve this through modification of the ARCH_CONSTRUCTOR macro (and several others that involve static global construction) to emit functions that call the constructors to fake the dead-stripper out. I haven't cracked the nut of making the macro work without adding an extra parameter though. Adding a parameter has a massive knock on effect in the codebase, so I don't currently have a nice solution to propose here.

[jilliene]

Filed as internal issue #USD-5808