-
Notifications
You must be signed in to change notification settings - Fork 326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crashes when linking against MaterialX libs from multiple shared libraries #485
Comments
One obstacle to the shared library builds could be the need to explicitly export public API on Windows. |
@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? |
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. |
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 I also ran valgrind on an internal test case and it appeared |
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. |
@sunyab I'll close this issue out for now, and let us know if additional shared library functionality is needed in the future. |
On Linux with g++ 6.3.1, when I link the MaterialX static libraries into two separate shared libraries, then use both of those shared libraries in a program, the program crashes at exit. I get the following diagnostic in the terminal:
To reproduce this, you can unpack the attached file, modify the build.sh script to point to your MaterialX install, then run it and the produced
test
program. repro.zipI don't think this is an issue specific to MaterialX itself. I'm not a linker expert but I think this is an expected gotcha with using static libraries with static variables with external linkage. I believe this could be avoided if I linked against a shared library build of MaterialX, but it appears only static builds are supported.
Could MaterialX allow shared library builds? Right now static builds are forced via the "STATIC" keyword specified in the add_library calls in the various CMakeList.txt files, but removing that let me build shared libraries that seemed to work OK in my limited testing.
The text was updated successfully, but these errors were encountered: