Closed Destranix closed 10 months ago
Okay, I resolved the issue. It was some kind of wrong usage: I was building the project in one folder, the copying the libraries to another folder. I did not copy the include files cause I assumed they were the same for all configurations. But they are not, they differ depending on the explicit instantiation macros.
Maybe one can create some kind of goard that rechecks the headers version before usage? At least fopr some cases?
Also some other thing that possobly would have avoided the thing to happen for me: I did not directly copy the files from the install folder, cause there were files missing in there (like .pdb) and the debug libraries had the same name as the release libraries (which makes it unsure to know which ones are currently installed). So maybe one could:
Environment
Operating System: Windows 10 Version / Commit SHA: (https://github.com/AcademySoftwareFoundation/openvdb/commit/9153c12ed095156aad18f4a0ca7f754b97eb83da) Other: (Shortened build log):
Describe the bug
When building openvdb without explicit instantiation some functions are unresolved. This does not occure when compiling with explicit instantiation.
To Reproduce
Steps to reproduce the behavior: Following build-script was used for compiling:
It occures in code with the following function:
The issue does not occure when outcommenting the rasterizeSpheres call. The issue does occure for both dynamic and shared libraries.
Expected behavior
All references should be resolved
Additional context
It's probably not connected, but when compiling openvdb in release configuration memory corruption errors occure (like during the call of AttributeSet::Descriptor::create the argument gets invalid). I guess that's an compiler failure. It does not occure with debug build (without explicit instantiations because unfortunatly the library gets too big).