[REQUEST] Improve documentation on building and linking for OpenVDB static library

[orbingol]

Is your feature request related to a problem? Please describe.

I have been trying to build OpenVDB as a static library and link it against one of my projects. There are bits and pieces in the issue tracker on what CMake variables to use for static linking and also there is OPENVDB_CORE_STATIC option while building OpenVDB. Still, I have been getting linking errors when I try to link against the "Hello World for OpenVDB" project in the cookbook. I am not sure if I am doing it correctly.

Here are the steps:

1. Uncheck OPENVDB_CORE_SHARED
2. Check USE_STATIC_DEPENDENCIES
3. Build OpenVDB
4. Setup CMake as described in the documentation (so that find_package works)
5. Compile hello world code: https://www.openvdb.org/documentation/doxygen/codeExamples.html#sHelloWorld

Describe the solution you'd like

It would be nice to have a simple tutorial on building and working with OpenVDB static library in the documentation.

Describe alternatives you've considered

Currently none.

Additional context

N/A

[Opioid]

I also have problems with actually using the statically built version of OpenVDB on windows. When I try to link a simple test program, I get a couple of errors. As far as I can tell some are related to ilmbase/half and some are related to blosc. Two examples:

`1>libopenvdb.lib(points.obj) : error LNK2001: unresolved external symbol "private: static short __cdecl half::convert(int)" (?convert@half@@CAFH@Z)

1>libopenvdb.lib(openvdb.obj) : error LNK2001: unresolved external symbol blosc_init`

In the source of the test program I have to define OPENVDB_STATICLIB, otherwise the linker won't find the openvdb symbols. I wonder if something comparable is required for the other libs?

[orbingol]

@Opioid I am not sure if it helps but have you tried defining BLOSC_USE_STATIC_LIBS and OPENVDB_USE_STATIC_LIBS before the find_package calls?

[Opioid]

Yes, this is what I did. I even used USE_STATIC_DEPENDENCIES=ON, which should set the individual flags for all dependencies as far as I understand. No success.

EDIT: It seems that the solution for building the test program, is to simply link to the other static dependencies as well. I had assumed it would all be contained in the resulting openvdb.lib.

[Idclip]

Hi folks, thanks for your feedback - I agree the static build workflow for VDB on Windows is not ideal and really needs some docs. In regards to your specific problems:

1. There are a number of symbols which are only used in the VDB headers and so do not get built into the final lib - you do still need to link your downstream software with all public dependencies (primarily half). Note that, as of VDB 8.1.0 (in dev, not released yet) VDB comes with it's own half definition which makes this dependency optional.

2. With regards to OPENVDB_STATICLIB, you should only need to define this if you're building a DLL but want to link to a static version of VDB. If you are building a downstream DLL then you'll most likely be building with /MD and the VDB headers will try to dllimport a bunch of stuff. Manually defining OPENVDB_STATICLIB suppresses this but could indicate you're mixing different versions of the CRT so I'd double check that's not happening.

The blosc one is interesting, I don't think you should ever need to link in blosc to your binaries. I will investigate.

[thomasmfields]

Did the documentation for building a static (.lib) version of OpenVDB ever materialize?