Attendance:

Guests:

• Vlad Lazar, Industrial Light & Magic

• Pierre-Anthony Lemieux, Sandflow Consulting

• Michael Smith, Intel / Wavelet Consulting

Discussion:

Quick Recap

The team discussed technical approaches for handling multiple versions of a core library, including symbol hiding and static linking methods to prevent conflicts between different plugins and shared objects. They explored potential issues with code duplication and thread pools, with Kimball explaining how TBB could address concerns about duplicate initialization. The conversation ended with discussions about maintaining C++-compiled core features and vendoring OpenJPH, with plans to reconvene after the holidays.

Next Steps

• Cary: merge the PR when I get a chance

• Kimball: review Cary's PR about building core with C++ and evaluate cleanup changes before it gets closed

• Cary: strip out worthwhile cleanup items from the PR for preservation

Summary

Core Library Versioning Strategy:Kimball explained a change he made to support multiple versions of a core library, inspired by how Windows handles DLLs. He described how the change forces the core library to act as a static library with hidden symbols when compiling, which helps prevent symbol exposure in shared objects like libopenexr.so. Kimball emphasized that this change is safe because he has carefully designed the core to be stateless, minimizing potential issues with static globals.

Custom OpenEXR Plugin Integration:Kimball and Cary discussed a technical approach where Vlad's new plugin would link against multiple custom versions of OpenEXR, embedded within the plugin's .so file. Kimball explained that this method would work for both the C++ and core APIs, hiding symbols and preventing conflicts with other plugins. Cary noted that while this approach would work, it would result in larger code space as the same modified core library would be included in multiple plugins. Peter briefly joined the conversation but did not make any additional contributions.

OpenEXR Linking Issues Resolved:The team discussed linking issues with OpenEXR and EXR utils, where Kimball explained that creating a custom OpenEXR.SO with static linking avoids symbol conflicts by making symbols hidden and no longer resolved at load time. Vlad raised a concern about potentially having two copies of EXR Core, which Peter confirmed was correct due to the EXR check file dependency, though he noted that EXR utils is not used in production and is only part of the distribution. The discussion clarified that while this setup might seem problematic, it actually solves both issues of preventing modified symbols from being picked up by other versions and avoiding conflicts with standard symbols.

Code Symbol Duplication Discussion:The team discussed the implications of duplicating code symbols, confirming that while it would result in duplicate symbols, the functionality would remain intact. They explored potential issues with static initialization and thread pools, with Kimball clarifying that Core has no thread pools and any concerns would arise from libopenexr. Peter raised a concern about custom namespaces potentially creating duplicate thread pools, but Kimball explained that switching to TBB would address this by using a single thread pool managed by TBB.

C++ Core Build Integration Discussion:The team discussed merging a PR and testing a C++ build of core. Kimball suggested creating an all-in-one header file approach similar to STB, though this hasn't been implemented yet. Cary agreed to keep his PR pending while Kimball reviews it for potential useful cleanup. Peter asked about making core always compileable with C++, but Kimball clarified this was not the current focus, as they are first interested in symbol versioning for C.

C++ Core Feature Documentation Update:The team discussed maintaining a C++-compiled core feature with minimal complexity, agreeing to keep it active but remove it from documentation to prevent unintended activation by distributors. Cary reported on vendoring OpenJPH, noting challenges due to its code duplication approach compared to LibDeflate, and Kimball confirmed that the current implementation is necessary for now. The conversation ended with plans to reconvene after the holidays, with Kimball and Cary noting their upcoming Christmas break.