Crashes when linking against MaterialX libs from multiple shared libraries about materialx

[sunyab]

One obstacle to the shared library builds could be the need to explicitly export public API on Windows.

[jstone-lucasfilm]

@sunyab Thanks for this detailed report! The first question that comes to my mind is: which global variable in the MaterialX library has external linkage? As a rule, we've aimed to declare all global variables as static or within anonymous namespaces (which should have the effect of giving them internal linkage in C++11). Do you happen to have access to the name of the global variable that is being destructed twice in your example?

[jstone-lucasfilm]

One possibility is that it's one of the two CreatorMap objects, which are declared as private static members of the Element and Value classes. If that's the case, then we could move these two variables to anonymous namespaces within Element.cpp and Value.cpp, which would give them internal linkage. Let us know, though, what variables seem to be triggering the crash in your example, and we'll proceed from there.

[sunyab]

In the repro case I posted I was unfortunately not able to figure out which string(s) were triggering this, but valgrind did report invalid accesses to MaterialX::ElementRegistry and MaterialX::ValueRegistry, which sounds like they could be the private static variables you mentioned. In addition, valgrind reported errors in the static destructor for Traversal.cpp and XmlIo.cpp. Here's the full valgrind report in case its useful: valgrind.txt

I also ran valgrind on an internal test case and it appeared MaterialX::UnitDef::UNITTYPE_ATTRIBUTE was one of the strings that valgrind flagged with an invalid free.

[jstone-lucasfilm]

Initial support for shared libraries on Linux and MacOS has been added in #487. Let us know if this addresses the issue you're running into.

[jstone-lucasfilm]

@sunyab I'll close this issue out for now, and let us know if additional shared library functionality is needed in the future.