openvdb icon indicating copy to clipboard operation
openvdb copied to clipboard

static build LNK2001 issue

Open ryein opened this issue 5 years ago • 7 comments

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...

  1. building everything through vcpkg using the triplet x64-windows-static
  2. 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).

ryein avatar Aug 26 '20 22:08 ryein

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.

Idclip avatar Aug 27 '20 10:08 Idclip

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.

ryein avatar Aug 27 '20 20:08 ryein

Is there any way you can provide the exact build output of MSVC?

Idclip avatar Aug 28 '20 11:08 Idclip

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

eliemichel avatar Jul 13 '21 16:07 eliemichel

Make sure that you are using Release mode

SimonNgj avatar Apr 03 '22 12:04 SimonNgj

What if we'd like to debug our code? Is there sth to change in the config?

eliemichel avatar Apr 04 '22 11:04 eliemichel

Try this: cmake --build . --parallel 4 --config Debug --target install

SimonNgj avatar Apr 04 '22 23:04 SimonNgj

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.

Idclip avatar Dec 07 '23 00:12 Idclip