openvdb
openvdb copied to clipboard
static build LNK2001 issue
I am using OpenVDB in a plugin I created for Grasshopper3D. I am trying to build it as a static library in order to minimize the DLLs that need to be packaged with the plugin. There is some trickery needed to get plugins with DLLs to work in Rhino/Grasshopper so I am trying to avoid that as much as possible.
Currently, I am able to successfully build an all static version of OpenVDB, but run into issue when I incorporate that into my own application. I have tried two different build strategies...
- building everything through vcpkg using the triplet x64-windows-static
- building OpenVDB and all its dependencies from scratch through CMAKE
Again, both compile a static OpenVDB succesfully, but they fail to build within my application. Both produce the following errors...
libopenvdb.lib(openvdb.obj) : error LNK2001: unresolved external symbol "private: static union half::uif const * const half::_toFloat" (?_toFloat@half@@0QBTuif@1@B)
libopenvdb.lib(Archive.obj) : error LNK2001: unresolved external symbol "private: static union half::uif const * const half::_toFloat" (?_toFloat@half@@0QBTuif@1@B)
libopenvdb.lib(points.obj) : error LNK2001: unresolved external symbol "private: static union half::uif const * const half::_toFloat" (?_toFloat@half@@0QBTuif@1@B)
libopenvdb.lib(openvdb.obj) : error LNK2001: unresolved external symbol "private: static unsigned short const * const half::_eLut" (?_eLut@half@@0QBGB)
libopenvdb.lib(Archive.obj) : error LNK2001: unresolved external symbol "private: static unsigned short const * const half::_eLut" (?_eLut@half@@0QBGB)
libopenvdb.lib(points.obj) : error LNK2001: unresolved external symbol "private: static unsigned short const * const half::_eLut" (?_eLut@half@@0QBGB)
I have looked over #625, #627, #654, #681 and most solutions seem to point towards using or not using different preprocessor directives like HALF_EXPORTS, OPENEXR_DLL, OPENVDB_OPENEXR_STATICLIB. That worked for me on previous builds of OpenVDB but for some reason I just can't get past those errors on this version. I have even tried different combinations of those when I build the OpenVDB and OpenEXR libraries from scratch.
Was just curious if anyone out there had any suggestions on things I could try to get up and running as I am sort of hitting a dead end right now. I am using Windows x64 with VS 2019 (MSVC 142).
Hello @ryein
The only preprocessor definition I believe you need is OPENVDB_OPENEXR_STATICLIB. OPENEXR_DLL should definitely not be present, if it is that will cause problems. I suspect that the way you're building OpenVDB is fine and that this is specific to your project's build command. How are you incorporating OpenVDB into your project, CMake/Make? Can you provide an example build command? If you're using OpenVDB's CMake to pull it in there may well be a problem there.
Right now I have been just trying to get it to compile in a very simple DLL project in VS. I have just been opening VS and creating a new project from the Dynamic Link Project template. The library loads through vcpkg automatically if I use that strategy or, in the case of me building all libraries myself, I manual link the library through the project properties. This was the method I used in my previous version of my application. I did have to turn off security checks (/SDL) in the past.
For this current project I have OPENVDB_OPENEXR_STATICLIB, NOMINMAX, OPENVDB_STATICLIB, and _USE_MATH_DEFINES as my preprocessor definitions.
Is there any way you can provide the exact build output of MSVC?
Hello, same problem here, I consolidated my attempt at making a minimal project using a static build of OpenVDB with MSVC16:
https://gist.github.com/eliemichel/54be942fec905611fc6840389496fd8e
Make sure that you are using Release mode
What if we'd like to debug our code? Is there sth to change in the config?
Try this: cmake --build . --parallel 4 --config Debug --target install
We've made a significant amount of changes to our half/exr dependency since this issue was posted so I'm going to close this. But please do make a new issue if this persists on the latest release.