Linking issues with static build on Windows, part 2.

[ftpronk]

This is a continuation of the effort started in #625.

The static build fails with the message:

openvdb_print.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) int __cdecl openvdb::v7_0::util::printBytes(clas
s std::basic_ostream<char,struct std::char_traits<char> > &,unsigned __int64,class std::basic_string<char,struct std::char_traits<cha
r>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const
 &,bool,int,int)" (__imp_?printBytes@util@v7_0@openvdb@@YAHAEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@_KAEBV?$basic_string@DU?$
char_traits@D@std@@V?$allocator@D@2@@5@2_NHH@Z) referenced in function "public: virtual void __cdecl openvdb::v7_0::tree::Tree<class
openvdb::v7_0::tree::RootNode<class openvdb::v7_0::tree::InternalNode<class openvdb::v7_0::tree::InternalNode<class openvdb::v7_0::tr
ee::LeafNode<int,3>,3>,4> > >::print(class std::basic_ostream<char,struct std::char_traits<char> > &,int)const " (?print@?$Tree@V?$Ro
otNode@V?$InternalNode@V?$InternalNode@V?$LeafNode@H$02@tree@v7_0@openvdb@@$02@tree@v7_0@openvdb@@$03@tree@v7_0@openvdb@@@tree@v7_0@o
penvdb@@@tree@v7_0@openvdb@@UEBAXAEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@H@Z) [C:\Code\openvdb\build\openvdb\cmd\vdb_print.v
cxproj]
openvdb_print.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl openvdb::v7_0::initialize(void)" (_
_imp_?initialize@v7_0@openvdb@@YAXXZ) referenced in function main [C:\Code\openvdb\build\openvdb\cmd\vdb_print.vcxproj]
C:\Code\openvdb\build\openvdb\cmd\Release\vdb_print.exe : fatal error LNK1120: 2 unresolved externals [C:\Code\openvdb\build\openvdb\
cmd\vdb_print.vcxproj]

Some changes were made, compared to the bug report #625 . The openvdb dependencies were mostly installed using vcpkg and x64-windows-static targets, except:

• c-blosc that was compiled manually to match the v1.5 requirements
• OpenEXR that was also compiled from source, due to some export leaks as described in #625,
• and zlib, that was compiled from source to bypass a bug discovered in: https://github.com/AcademySoftwareFoundation/openexr/issues/648.

OpenEXR was compiled using:

cmake -DBUILD_SHARED_LIBS=OFF -DPYILMBASE_ENABLE=OFF -OPENEXR_VIEWERS_ENABLE=OFF ..
cmake.exe --build . --target install --config Release

And OpenVDB was compiled with:

cmake -DCMAKE_TOOLCHAIN_FILE=C:\vcpkg\scripts\buildsystems\vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static -DOPENVDB_CORE_SHARED=OFF ..
cmake.exe --build . --target install --config Release

Compiling OpenEXR required some changes:

• The base CMakeLists.txt file of the OpenEXR project was slightly modified to include:

  cmake_policy(SET CMP0091 NEW)

  and, on the first line after the project definition:

  set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

  This requires CMake >= 3.15. It was needed to circumvent the build error:

  Half-2_4.lib(half.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_Sta
  ticRelease' in openvdb_print.obj [C:\Code\openvdb\build\openvdb\cmd\vdb_print.vcxproj]

• The export leaks was addressed by modifying ` ./OpenEXR/IlmBase/Half/halfExport.h' to:

  #if defined(OPENEXR_DLL)
  #define HALF_EXPORT
  #define HALF_EXPORT_CONST const
  #else
  #define HALF_EXPORT
  #define HALF_EXPORT_CONST const
  #endif

  I.e. removing the __declspec(dllexport) and __declspec(dllimport)

The OpenVDB code also required some changes:

• Once more the base CMakeLists.txt file was slightly modified to include:

  cmake_policy(SET CMP0091 NEW)

  and, on the first line after the project definition:

  set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

  This requires CMake >= 3.15. It was needed to circumvent the build error:

  tbb.lib(task.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRe
  lease' in openvdb_print.obj [C:\Code\openvdb\build\openvdb\cmd\vdb_print.vcxproj]

  (This might warrant a different bug report later)

[Idclip]

@ftpronk, this is still a bit of a work in progress, however I have a PR here which looks to address a lot of these static build issues: https://github.com/AcademySoftwareFoundation/openvdb/pull/654

[Idclip]

My workflow with the changes for #654 is as follows:

vcpkg install tbb openexr blosc zlib boost --triplet x64-windows-static
vcpkg integrate install

git clone git@github.com:AcademySoftwareFoundation/openvdb.git
cd openvdb
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=<PATH_TO_VCPKG>\scripts\buildsystems\vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static -A x64 -DUSE_STATIC_DEPENDENCIES=ON ..
cmake --build . --parallel 4 --config Release --target install

[ftpronk]

I gave your pull request a try, but I wasn't successful yet..

To get anywhere, I needed to add the following define flag to cmake:

-DOPENVDB_CORE_SHARED=OFF

But even that wasn't enough. I get dll linkage warnings similar to this one:

C:\Code\openvdb2\openvdb\Grid.cc(19,41): warning C4273: 'META_GRID_CLASS': inconsistent dll linkage [C:\Code\openvdb2\build\openvdb\openvdb_static.vcxproj]

And also full errors. This is the first one I get:

C:\Code\openvdb2\openvdb\Grid.cc(19,41): error C2491: 'openvdb::v7_1::GridBase::META_GRID_CLASS': definition of dllimport static data member not allowed [C:\Code\openvdb2\build\openvdb\openvdb_static.vcxproj]

[Idclip]

Hey @ftpronk, hmm okay interesting, can you post the full CMake command you're running?

[ftpronk]

As a side question, I see you use the blosc package from vcpkg. When I try to compile OpenVDB with it, I get the following warning:

-- Found Blosc: C:/_local/lib/blosc.lib (found suitable version "1.17", minimum required is "1.5")
CMake Warning at openvdb/CMakeLists.txt:89 (message):
The version of Blosc located is greater than 1.5.  There have been reported
  issues with using later versions of Blosc with OpenVDB.  OpenVDB has been
  tested fully against Blosc 1.5, it is recommended that you use this version
  where possible.

Is that warning still valid, or can it be ignored?

[ftpronk]

Hey @ftpronk, hmm okay interesting, can you post the full CMake command you're running?

Sure.

cmake -DCMAKE_TOOLCHAIN_FILE=C:\vcpkg\scripts\buildsystems\vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static -A x64 -DUSE_STATIC_DEPENDENCIES=ON -DOPENVDB_CORE_SHARED=OFF  ..
cmake --build . --config Release --target install

[Idclip]

@ftpronk I can reproduce your issue, I'm not sure how I missed it... I think some of the CMake aliasing options I've tried to put in aren't working. Instead, can you try the same CMake command (in a fresh build directory) with -DUSE_WINDOWS_STATIC_RUNTIME=ON:

cmake -DCMAKE_TOOLCHAIN_FILE=C:\vcpkg\scripts\buildsystems\vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static -A x64 -DUSE_STATIC_DEPENDENCIES=ON -DOPENVDB_CORE_SHARED=OFF -DUSE_WINDOWS_STATIC_RUNTIME=ON  ..

[Idclip]

@ftpronk were you able to make any progress?

[ftpronk]

Yes, progress was made. I was able to get openvdb to compile with the new cmake command you provided.

Unfortunately I then encountered a build error when building our own application:

C:\local\include\openvdb\Types.h(9,10): fatal error C1083: Cannot open include file: 'OpenEXR/half.h': No such file or directory

I suspect that might be linked to the way we are looking for OpenVDB in our CMake setup. We had to implement our own search as the option described in the openvdb documentation did not work. For reference, the instructions in the documentation read:

list(APPEND CMAKE_MODULE_PATH "/location/of/openvdb/install/lib/cmake/OpenVDB")
find_package(OpenVDB REQUIRED)
target_link_libraries(myapp OpenVDB::openvdb)

Which leads to the following:

  By not providing "FindOpenVDB.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "OpenVDB", but
  CMake did not find one.

  Could not find a package configuration file provided by "OpenVDB" with any
  of the following names:

    OpenVDBConfig.cmake
    openvdb-config.cmake

  Add the installation prefix of "OpenVDB" to CMAKE_PREFIX_PATH or set
  "OpenVDB_DIR" to a directory containing one of the above files.  If
  "OpenVDB" provides a separate development package or SDK, be sure it has
  been installed.

I'm not quite sure if the OpenEXR header error can be considered a part of this bug report, though it is interesting that it didn't show up when we were using OpenVDB with dynamic library linking..

[Idclip]

Hi @ftpronk sorry for my late reply - did you have any further success in compiling your own application? If not could you share with me the exact find_package() calls and CMAKE_MODULE_PATH appends you're using?

[Idclip]

Closing due to inactivity - @ftpronk please absolutely re-open if you have further questions or comments