Open Idclip opened 4 years ago
@ianww I've created a new issue to track this.
This seems to be an issue with our CMake Find modules for locating the correctly named libs specifically on Windows for Houdini. I should preface the following with the fact that we do not currently have CI for building against Houdini on Windows, so I'm just guessing with the below suggestion.
Firstly, as to why it's reporting that it's found a suitable versions "2.2" - There are two main CMake variables which control how dependencies are found. <Package>_ROOT
and <PACKAGE>_INCLUDEDIR/_LIBRARYDIR
(see https://www.openvdb.org/documentation/doxygen/build.html#buildDependencies). <PACKAGE>_INCLUDEDIR/_LIBRARYDIR
are prioritised and set to point to your Houdini installation when building for Houdini. Houdini 17.5 deploys with IlmBase/OpenExr 2.2, hence why CMake is reporting it's found a suitable set of headers.
ILMBASE_LIBRARYDIR
should be being set to the location of Houdini's 3rdparty libs e.g: "C:/Program Files/Side Effects Software/Houdini 17.5.425/dsolib/"
. In this folder you should find Half-2_2.lib
. My guess is that it's named in some way that our CMake modules aren't parsing it correctly. Could you confirm that this file exists and it's name in your Houdini installation? (I don't have access to a Windows machine :( ). One thing you could try is manually providing the component to CMake:
cmake `
-S"C:/vcpkg/openvdb" `
-G"Visual Studio 16 2019" `
-DCMAKE_TOOLCHAIN_FILE="C:/vcpkg/scripts/buildsystems/vcpkg.cmake" `
-DHoudini_ROOT="C:/Program Files/Side Effects Software/Houdini 17.5.425" `
-DOPENVDB_BUILD_HOUDINI_PLUGIN=ON `
-DUSE_DEFAULT_HOUDINI_INSTALL=ON `
-DIlmBase_Half_LIBRARY="C:/Program Files/Side Effects Software/Houdini 17.5.425/dsolib/LIB_NAME_HERE" `
..
Fabulous! That worked!
I found the dsolib buried a bit deeper, at:
C:\Program Files\Side Effects Software\Houdini 17.5.425\custom\houdini\dsolib
I added:
-DIlmBase_Half_LIBRARY=”C:\Program Files\Side Effects Software\Houdini 17.5.425\custom\houdini\dsolib/Half.lib”
to the CMake command, and got a successful CMake build.
My full successful command is now:
cmake `
-S"C:/vcpkg/openvdb" `
-G"Visual Studio 16 2019" `
-DOPENVDB_ABI_VERSION_NUMBER=5 `
-DCMAKE_TOOLCHAIN_FILE="C:/vcpkg/scripts/buildsystems/vcpkg.cmake" `
-DHoudini_ROOT="C:/Program Files/Side Effects Software/Houdini 17.5.425" `
-DUSE_HOUDINI=ON `
-DOPENVDB_BUILD_HOUDINI_PLUGIN=ON `
-DUSE_DEFAULT_HOUDINI_INSTALL=ON `
-DOPENVDB_BUILD_PYTHON_MODULE=ON `
-DOPENVDB_BUILD_UNITTESTS=ON `
-DOPENEXR_ROOT="C:/vcpkg/installed/x64-windows" `
-DIlmBase_Half_LIBRARY=”C:/Program Files/Side Effects Software/Houdini 17.5.425/custom/Houdini/dsolib/Half.lib” `
-DTBB_ROOT="C:/vcpkg/installed/x64-windows" `
-DUSE_BLOSC=OFF `
-DCPPUNIT_ROOT="C:/vcpkg/installed/x64-windows" `
-DBOOST_ROOT="C:/vcpkg/installed/x64-windows" `
-DBOOST-PYTHON_ROOT="C:/vcpkg/installed/x64-windows" `
-DBOOST_LIBRARYDIR="C:/vcpkg/installed/x64-windows" `
-DZLIB_ROOT="C:/vcpkg/installed/x64-windows" `
..
I got Solution Build errors when I moved on to the Visual Studio build stage but I'll work my way through them - I haven't yet properly researched how to do that stage, and I may be doing something fundamentally wrong. At least I've now made it out of CMake!
A thousand thanks!
Nup, I need more help! I get hundreds of errors when trying to do a Visual Studio build.
After the successful CMake build, I have in the C:\vcpkg\openvdb\build directory an OpenVDB.sln.
Also in that directory I have an openvdb directory containing its own OpenVDBCore.sln and an openvdb_houdini directory containing its own OpenVDBHoudini.sln.
I've assumed that I need to build the subsidiary OpenVDBCore.sln and OpenVDBHoudini.sln first and then build the overarching OpenVDB.sln.
I can build OpenVDBCore.sln with no errors. It creates a release folder containing:
Libopenvdb.lib
Openvdb.dll
Openvdb.exp
Openvdb.lib
However, when I then move on to try and build OpenVDBHoudini.sln I get hundreds of errors. Almost all of them are of the following forms:
function parameter lists do not match between declarations
you cannot overload a function with 'extern "C"' linkage
function parameter lists do not match between declarations
Am I doing something fundamentally wrong with my Studio Build approach?
BTW if I don't try and build OpenVDBCore.sln and/or OpenVDBHoudini.sln first but instead go straight to building OpenVDB.sln, I get the same types of errors.
I've managed to make heaps of progress. I restarted completely from scratch using a combination of vcpkg and Visual Studio's CMake, and I can both understand and edit the build process much better now. I've managed to successfully generate the CMake files for building OpenVDB against Houdini Apprentice 17.5 in Windows 10.
However, when I try to build (in Visual Studio) with the resulting CMakeLists file, I get one error:
'C:/Program Files/Side Effects Software/Houdini 17.5.425/dsolib/libHoudiniRAY.so', needed by 'openvdb_houdini/openvdb_houdini.lib', missing and no known rule to make it
From looking at:
https://github.com/AcademySoftwareFoundation/openvdb/blob/master/cmake/OpenVDBHoudiniSetup.cmake
it appears that libHoudiniRAY.so, together with libhboost_regex.so and libhboost_thread.so, are Houdini extra libraries that get appended from somewhere.
None of these appear in Houdini's dsolib (which in my case is actually at C:\Program Files\Side Effects Software\Houdini 17.5.425\custom\houdini\dsolib), and I can't see them anywhere else in the Houdini 17.5.425 directory either.
Because they're extras, I've thought of just finding where they're called from and commenting out the call but I've searched for the string libHoudiniRAY through all the files inside my openvdb and openvdb_houdini directories and also inside Houdini 17.5.425 and it doesn't exist anywhere.
So, I'm at a loss to know why the error is occurring in the first case and then what to do to fix or go round it.
I'd be really grateful if someone could provide me with some guidance on this.
The above hiccup error is now solved - in CMakeSettings I changed my CMake generator from the default Ninja to Visual Studio 16 2019 Win64 (and removed the default -v from the Build command arguments field).
However, when then moving onto the build I returned to getting the same types of errors as before :( .
Primarily:
function parameter lists do not match between declarations
you cannot overload a function with 'extern "C"' linkage
function parameter lists do not match between declarations
Looking at the errors, most relate to hboost. Researching this, I've found from https://www.sidefx.com/docs/hdk/_h_d_k__changes_16_5.html that hboost are Houdini's custom boost libraries that replace the standard boost libraries. I think the errors are therefore due to ambiguity between boost and hboost.
The site says:
Alternatively, you can use the custom Boost libraries that ship with the HDK. This requires porting code to work with the hboost namespace instead of the boost namespace. This generally involves making three changes to code:
Change references to the boost namespace to hboost instead.
Change references to BOOST_* preprocessor variables to HBOOST_* instead.
Change <boost/...> header includes to <hboost/...> instead.
It also involves linking against hboost libraries by replacing -lboost_iostreams with -lhboost_iostreams for example.
In my CMake file I've replaced references to BOOST with HBOOST, and I've pointed it to the Houdini custom directory:
-DHBOOST_ROOT=”C:/Program Files/Side Effects Software/Houdini 17.5.425/custom/Houdini/dsolib”
However, this now gives me missing boost errors:
"C:/Program Files/Side Effects Software/Houdini 17.5.425/custom/Houdini/bin/boost/version.hpp" cannot be read.
Imported targets and dependency information not available for Boost version 0.0.0 (all versions older than 1.33)
Could NOT find Boost: Found unsuitable version "0.0.0", but required is at least "1.61" (found C:/Program Files/Side Effects Software/Houdini 17.5.425/custom/Houdini/bin)
Can anyone please help me with this? How do I remove the ambiguity between boost and hboost without the build thinking that boost is missing?
Can I do it via CMake or do I need to dig down into code?
Hello @ianww,
As you've pointed out, the issues you're running into are due to the ambiguity of your custom libraries conflicting with Houdini's deployed libraries. The main problem is due to missing functionality in OpenVDBHoudiniSetup.cmake
for Windows. I managed to take a look at the Houdini windows install and have made an attempt to update this file to properly handle windows installations. As mentioned, we do not have CI/tests for this so hopefully I can continue to work with you to get this to build.
The changes I'm proposing are here: https://github.com/AcademySoftwareFoundation/openvdb/pull/606
I'll also elaborate on the OpenVDB/Houdini build a little. Houdini 17.5 comes with the following dependencies for OpenVDB: IlmBase, OpenEXR, TBB, Blosc, Boost and ZLIB. Of these, only IlmBase, OpenEXR and Boost are properly namespaced (@jmlait can correct me if I'm wrong here). This means that you must use the TBB, Blosc and ZLIB installations that come with Houdini to ensure compatibility and can optionally use either your own builds of OpenEXR and IlmBase or the Houdini builds. Boost is unfortunately a bit convoluted. The Houdini Boost deployment isn't only namespaced, it also has its own unique directory hboost
. The core OpenVDB library will only build against your own version of Boost because of this, where as the Houdini plugin specifically looks for hboost/blah.h
. This doesn't cause an issue because everything is namespaced, but does mean that you need to use your own version of Boost for the core library and the Houdini version hboost
for the Houdini plugin.
I would advise to use all libraries that deploy with Houdini, including IlmBase and OpenEXR, to make things easier. With the above fixes, you should be able to run the following. Note the -DCMAKE_GENERATOR_PLATFORM=x64
which you may need to ensure that your vcpkg builds are being picked up. If it still fails to find Boost, try adding back in -DBOOST_ROOT="C:/vcpkg/installed/x64-windows"
:
cmake `
-S"C:/vcpkg/openvdb" `
-G"Visual Studio 16 2019" `
-DCMAKE_TOOLCHAIN_FILE="C:/vcpkg/scripts/buildsystems/vcpkg.cmake" `
-DHoudini_ROOT="C:/Program Files/Side Effects Software/Houdini 17.5.425" `
-DCMAKE_GENERATOR_PLATFORM=x64
-DOPENVDB_BUILD_HOUDINI_PLUGIN=ON `
-DUSE_DEFAULT_HOUDINI_INSTALL=ON `
..
I've removed the unit test and python module from the above just to make things simpler to begin with.
Many thanks for that!
As you suggested, I'm now using Houdini's TBB, Blosc and zlib. I've also used Houdini's Ilmbase libs (which have a _sidefx suffix) and I'm using my own installation of boost, and leaving Houdini to look for hboost.
Houdini's available zlib files weren't explicit matches to each other, being zdll.lib, zlib1.dll and zlib.h but I presume that it knows what it's doing and can match them.
Your comments also prompted me to relook at my CMakeSettings in Visual Studio and I realised that I had not ticked Show Advance Settings in the CMake variables section. Once I ticked that some NOT FOUND variables showed up, which I could then add paths for.
FYI my build has the following options turned ON:
option(OPENVDB_BUILD_CORE "Enable the core OpenVDB library. Both static and shared versions are enabled by default" ON)
option(OPENVDB_BUILD_BINARIES "Enable the vdb binaries. Only vdb_print is enabled by default" ON)
option(OPENVDB_BUILD_PYTHON_MODULE "Build the pyopenvdb Python module" ON)
option(OPENVDB_BUILD_UNITTESTS "Build the OpenVDB unit tests" ON)
option(OPENVDB_BUILD_HOUDINI_PLUGIN "Build the Houdini plugin" ON)
option(OPENVDB_INSTALL_HOUDINI_PYTHONRC [=[Install a Houdini startup script that sets the visibilty of OpenVDB nodes and their native equivalents.]=] ON)
When I built the CMakeLists this time, all the hboost errors had disappeared. Yay!
I got only 1 error.
LNK1181 cannot open input file 'C:\Program.obj'
The error occurred in C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj, so appears to have happened during the output of the build.
Presumably because of this error, Visual Studio said the build failed.
However, it also said:
Generating Code...
openvdb_static.vcxproj -> C:\vcpkg\openvdb\out\build\x64-Release\openvdb\Release\libopenvdb.lib
and when I looked in that folder there was a 39 Mb libopenvdb.lib file, but nothing else.
I presume that there should be at least a bin file(s) also, and that its absence is related to the above error.
I now need to work out how to resolve that.
EDIT - got that sorted - VS CMake was truncating paths at spaces, even though the paths were in quotes. Fixed, and got rid of the error. BUT - at the same time I did a few clean-up tweaks to the settings and now the hboost errors are back, and I've been unable to untweak them away! Aargghh, frustrating. I'll keep at it.
Thanks again for your help!
I can't get rid of those errors :(.
I made your suggested changes to the OpenVDBHoudiniSetup.cmake file.
In my CMake settings, the only dependency from my vcpkg installation that I call up is boost.
When configuring OpenVDBCore, CMake found ilmbase, tbb, zlib and blosc from the Houdini installation and boost from my installation.
When configuring OpenVDBBinaries, CMake found ilmbase and OpenEXR from the Houdini installation.
When configuring OpenVDBHoudini, CMake didn't mention any dependencies. I presume that this is because it doesn't need any external dependencies, due to Houdini having its own copies or versions within its installation.
I get a successful cache generation. Something that may be relevant is that when doing the generation, for both the OpenVDBCore and OpenVDBBinaries configuration steps I get an error:
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
From googling it seems that this is not critical, and it obviously doesn't stop a successful generation of the cache but perhaps it does have some involvement in my particular errors? I don't know how to create a pkg-config, and I'd appreciate some guidance if it is indeed important.
My full warning and error output from my build attempt is below and following that is my output window's verbage. Any further advice you might be able to give me would be be great!
```
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning (dev) at C:/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package):
Policy CMP0074 is not set: find_package uses
```
>------ Build started: Project: CMakeLists, Configuration: Release ------
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Checking Build System
Building Custom Rule C:/vcpkg/openvdb/openvdb/CMakeLists.txt
Grid.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Archive.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\Archive.cc(1085,1): warning C4996: 'getenv': This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdlib.h(1191): message : see declaration of 'getenv' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
Compression.cc
C:\vcpkg\openvdb\openvdb\io\Compression.cc(85,35): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\Compression.cc(213,34): warning C4146: unary minus operator applied to unsigned type, result still unsigned
DelayedLoadMetadata.cc
File.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\File.cc(74,1): warning C4996: 'getenv': This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdlib.h(1191): message : see declaration of 'getenv' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
GridDescriptor.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Queue.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Stream.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
TempFile.cc
C:\vcpkg\openvdb\openvdb\io\TempFile.cc(100,1): warning C4996: 'tmpnam': This function or variable may be unsafe. Consider using tmpnam_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdio.h(440): message : see declaration of 'tmpnam' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
Maps.cc
Proximity.cc
QuantizedUnitVec.cc
Transform.cc
Metadata.cc
MetaMap.cc
openvdb.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\math\Math.h(81,54): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\..\openvdb/io/Compression.h(506): message : see reference to function template instantiation 'T openvdb::v7_0abi5::math::negative
It seems like this is an issue with Boost and VS 19. A bit of googling threw up this thread on the VS dev community:
Specifically, the comments suggest enabling the /Zc:externC
switch. Could you try this for Houdini project?
As I understand it, setting compiler switches in VS is done via a project's property pages. However, VS CMake doesn't have any proj files, so I can't open any property page to add this switch to (I think proj files are built temporarily on the run during the build but there's no way to access them).
I therefore tried to set compiler switches in CMake settings by adding /Zc:externC- as a build command argument. The cache generated OK but when I tried a build I got an "unknown switch" error.
I then took a random guess and tried adding add_compile_options(/Zc:externC-)
directly into the CMakeLists.txt file. (Perhaps I could have instead done this with some sort of -DCMAKE... command line? If so, I don't know what that would be.)
I've no idea whether this is a right thing to do or not but it did achieve something - the previous 59 errors that I was getting disappeared. However, I got 5 new errors:
Error C2491 'openvdb_houdini::VDBPointsGroupMenuInput1': definition of dllimport data not allowed C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.vcxproj C:\vcpkg\openvdb\openvdb_houdini\PointUtils.cc 1810
Error C2491 'openvdb_houdini::VDBPointsGroupMenuInput2': definition of dllimport data not allowed C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.vcxproj C:\vcpkg\openvdb\openvdb_houdini\PointUtils.cc 1812
Error C2491 'openvdb_houdini::VDBPointsGroupMenuInput3': definition of dllimport data not allowed C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.vcxproj C:\vcpkg\openvdb\openvdb_houdini\PointUtils.cc 1814
Error C2491 'openvdb_houdini::VDBPointsGroupMenuInput4': definition of dllimport data not allowed C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.vcxproj C:\vcpkg\openvdb\openvdb_houdini\PointUtils.cc 1816
Error C2491 'openvdb_houdini::VDBPointsGroupMenu': definition of dllimport data not allowed C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.vcxproj C:\vcpkg\openvdb\openvdb_houdini\PointUtils.cc 1819
****
These don't seem to be related to the previous errors, so it appears that the hboost issue may have been resolved (hopefully...!).
Looking at the PointUtils.cc file, the new errors all occur here:
#ifdef _MSC_VER
OPENVDB_HOUDINI_API const PRM_ChoiceList
VDBPointsGroupMenuInput1(PRM_CHOICELIST_TOGGLE, sopBuildVDBPointsGroupMenu);
OPENVDB_HOUDINI_API const PRM_ChoiceList
VDBPointsGroupMenuInput2(PRM_CHOICELIST_TOGGLE, sopBuildVDBPointsGroupMenu);
OPENVDB_HOUDINI_API const PRM_ChoiceList
VDBPointsGroupMenuInput3(PRM_CHOICELIST_TOGGLE, sopBuildVDBPointsGroupMenu);
OPENVDB_HOUDINI_API const PRM_ChoiceList
VDBPointsGroupMenuInput4(PRM_CHOICELIST_TOGGLE, sopBuildVDBPointsGroupMenu);
OPENVDB_HOUDINI_API const PRM_ChoiceList VDBPointsGroupMenu(PRM_CHOICELIST_TOGGLE,
sopBuildVDBPointsGroupMenu);
#else
The Intellisense error popups say:
variable "openvdb_houdini::VDBPointGroupMenuInput1" may not be initialized
variable "openvdb_houdini::VDBPointGroupMenuInput2" may not be initialized
variable "openvdb_houdini::VDBPointGroupMenuInput3" may not be initialized
variable "openvdb_houdini::VDBPointGroupMenuInput4" may not be initialized
variable "openvdb_houdini::VDBPointGroupMenu" may not be initialized
I can see from Intellisense that _MSV_VER is indeed defined, and it's 1924, which is Visual Studio 2019 ver 16.4, which is what I'm using.
So, despite the code entering this ifdef, somehow these variables are not being initialized inside it.
Drilling down further (and I'm no expert programmer, so this is getting beyond me...), this seems to be something to do with OPENVDB_HOUDINI_API OPENVDB_IMPORT.
If I go to the declarations of OPENVDB_HOUDINI and OPENVDB_IMPORT it shows them occurring in C:\vcpkg\openvdb\openvdb\Platform.h.
Perhaps I have a wrong or no OPENVDB_HOUDINI_API setting somewhere, that Platform.h can't find?
I'd be really grateful if you could provide your thoughts on these new errors, and also whether you think my adding the code directly to the CMakeLists file was a legitimate approach - I'm worried that even though the old errors appear to be gone, they might just be lurking in the background behind these new errors.
I won't be able to get back to this for a couple of days now but in the interim if you have any more suggestions I'd be really pleased to hear them!
Thanks again!
I'd be really grateful if you could provide your thoughts on these new errors, and also whether you think my adding the code directly to the CMakeLists file was a legitimate approach
Yes, I believe the way you've added that switch is correct (sorry I should have been more explicit). I don't think you need the trailing -
(i.e. add_compile_options(/Zc:externC)
vs add_compile_options(/Zc:externC-)
), but in either case it seems it has worked for now. Lets continue and see if this has correctly resolved the hboost issues,.
Regarding the new errors, this may be due to a missing define in our CMake for the openvdb_houdini library. This is a shared library (dll) which is built before any of the Houdini nodes (SOPs/SHOPs/etc) and as such needs some of its methods to be marked as exported via the OPENVDB_HOUDINI_PRIVATE
define (for reference, the core library uses a OPENVDB_PRIVATE
define which is set in openvdb/CMakeLists.txt
). We only want to apply the define to the openvdb_houdini lib, not the node libs. Could you try adding the following to the openvdb_houdini/CMakeLists.txt
around line 183:
target_compile_definitions(openvdb_houdini PRIVATE "-DOPENVDB_HOUDINI_PRIVATE")
Yes, that fixed those errors! And another lot appeared...
BTW - the trailing dash in add_compile_options(/Zc:externC-)
does in fact seem to be needed. I took out the dash (to make it add_compile_options(/Zc:externC)
) and the hboost errors reappeared. I put the dash back in and they went away again.
Also gone with the hboost errors are all the "inconsistent dll linkage warnings" that preceded them.
Adding in
target_compile_definitions(openvdb_houdini PRIVATE "-DOPENVDB_HOUDINI_PRIVATE")
to the openvdb_houdini/CMakeLists.txt
as you suggested got rid of the "not initialized" errors relating to OPENVDB_HOUDINI_API OPENVDB_IMPORT too, so that's great.
The new errors are two LINK2001 errors and four LINK2019 errors, from a total of 4 unresolved externals. I've copied in the full warning/error summary and output below.
I noticed that there was a target_compile_definitions
a bit further on in the openvdb_houdini/CMakeLists.txt
file (around line 218) within an if statement related to OPENVDB_HOUDINI_OPHIDE_POLICY:
if (OPENVDB_HOUDINI_OPHIDE_POLICY AND NOT ${OPENVDB_HOUDINI_OPHIDE_POLICY} STREQUAL "none")
target_compile_definitions(openvdb_houdini PRIVATE
"-DOPENVDB_OPHIDE_POLICY=${OPENVDB_HOUDINI_OPHIDE_POLICY}")
endif()
From googling, I understand that the ophide is to hide/not hide duplicate SOPs. So I wonder whether the ophide is hiding SOPs but not properly letting the compiler know, and it's trying to link to them but can't because they're hidden?
```
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning (dev) at C:/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package):
Policy CMP0074 is not set: find_package uses
```
>------ Build started: Project: CMakeLists, Configuration: Release ------
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Checking Build System
Building Custom Rule C:/vcpkg/openvdb/openvdb/CMakeLists.txt
Grid.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Archive.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\Archive.cc(1085,1): warning C4996: 'getenv': This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdlib.h(1191): message : see declaration of 'getenv' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
Compression.cc
C:\vcpkg\openvdb\openvdb\io\Compression.cc(85,35): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\Compression.cc(213,34): warning C4146: unary minus operator applied to unsigned type, result still unsigned
DelayedLoadMetadata.cc
File.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\File.cc(74,1): warning C4996: 'getenv': This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdlib.h(1191): message : see declaration of 'getenv' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
GridDescriptor.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Queue.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Stream.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
TempFile.cc
C:\vcpkg\openvdb\openvdb\io\TempFile.cc(100,1): warning C4996: 'tmpnam': This function or variable may be unsafe. Consider using tmpnam_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdio.h(440): message : see declaration of 'tmpnam' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
Maps.cc
Proximity.cc
QuantizedUnitVec.cc
Transform.cc
Metadata.cc
MetaMap.cc
openvdb.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\math\Math.h(81,54): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\..\openvdb/io/Compression.h(506): message : see reference to function template instantiation 'T openvdb::v7_0abi5::math::negative
Hmm I'm a bit stumped with this one, @jmlait @e4lam any ideas? These are the specific symbol errors:
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/Release/openvdb_houdini.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/Release/openvdb_houdini.exp
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GEO_VDBTranslator.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v7_0abi5@openvdb@@XZ) referenced in function "bool __cdecl `anonymous namespace'::fileSaveVDB<class openvdb::v7_0abi5::io::File,char const *>(class GEO_Detail const *,char const *)" (??$fileSaveVDB@VFile@io@v7_0abi5@openvdb@@PEBD@?A0x709f137f@@YA_NPEBVGEO_Detail@@PEBD@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GT_GEOPrimCollectVDB.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v7_0abi5@openvdb@@XZ)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_NodeVDB.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v7_0abi5@openvdb@@XZ)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\PointUtils.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::shared_ptr<class openvdb::v7_0abi5::GridBase const > __cdecl GEO_PrimVDB::getConstGridPtr(void)const " (__imp_?getConstGridPtr@GEO_PrimVDB@@QEBA?AV?$shared_ptr@$$CBVGridBase@v7_0abi5@openvdb@@@std@@XZ) referenced in function "void __cdecl openvdb_houdini::`anonymous namespace'::sopBuildVDBPointsGroupMenu(void *,class PRM_Name *,int,class PRM_SpareData const *,class PRM_Parm const *)" (?sopBuildVDBPointsGroupMenu@?A0xd9fa97c0@openvdb_houdini@@YAXPEAXPEAVPRM_Name@@HPEBVPRM_SpareData@@PEBVPRM_Parm@@@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_NodeVDB.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase & __cdecl GEO_PrimVDB::getGrid(void)" (__imp_?getGrid@GEO_PrimVDB@@QEAAAEAVGridBase@v7_0abi5@openvdb@@XZ) referenced in function "protected: virtual enum UT_ErrorSeverity __cdecl openvdb_houdini::SOP_NodeVDB::cookMyGuide1(class OP_Context &)" (?cookMyGuide1@SOP_NodeVDB@openvdb_houdini@@MEAA?AW4UT_ErrorSeverity@@AEAVOP_Context@@@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Utils.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class GU_PrimVDB * __cdecl GU_PrimVDB::buildFromGrid(class GU_Detail &,class std::shared_ptr<class openvdb::v7_0abi5::GridBase>,class GEO_PrimVDB const *,char const *)" (__imp_?buildFromGrid@GU_PrimVDB@@SAPEAV1@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v7_0abi5@openvdb@@@std@@PEBVGEO_PrimVDB@@PEBD@Z) referenced in function "class GU_PrimVDB * __cdecl openvdb_houdini::createVdbPrimitive(class GU_Detail &,class std::shared_ptr<class openvdb::v7_0abi5::GridBase>,char const *)" (?createVdbPrimitive@openvdb_houdini@@YAPEAVGU_PrimVDB@@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v7_0abi5@openvdb@@@std@@PEBD@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Release\openvdb_houdini.dll : fatal error LNK1120: 4 unresolved externals
These are all member header methods which are not marked as inline. Could this be an issue with the Houdini headers?
@Idclip Which compiler version and Houdini version?
From what I can determine from the above:
> Visual Studio 16 2019 (Build Engine version 16.4.0+e901037fe)
> Houdini 17.5.425
If it's any help to your thinking, despite the build failing these files appeared in C:\vcpkg\openvdb\out\build\x64-Release\openvdb\Release:
and these files appeared in C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Release:
Ah, ok, yeah, I had run into this myself but with my local experimental clang-cl build. In dev trunk now, all of these methods have SYS_FORCE_INLINE
added to them. I'll backport them to H18. In the mean time, you can try locally modifying $HT/include/GEO/GEO_PrimVDB.h
to have SYS_FORCE_INLINE
on all the methods that give you linker errors.
Change should show up in tomorrow's daily Houdini 18.0.352 build.
Thanks a lot @e4lam - I was hoping that I could mark these methods within the VDB copies of GEO/GU_PrimVDB and build with -DSESI_OPENVDB_PRIM
but they seem to be out of sync. I've be able to fix most of the issues except for an error in GU_PrimVDB::registerMyself(GA_PrimitiveFactory *factory)
:
.../openvdb_houdini/GU_PrimVDB.cc: In static member function ‘static void GU_PrimVDB::registerMyself(GA_PrimitiveFactory*)’:
.../openvdb_houdini/GU_PrimVDB.cc:514:38: error: invalid conversion from ‘GA_Primitive* (*)(GA_Detail&, GA_Offset, const GA_PrimitiveDefinition&) {aka GA_Primitive* (*)(GA_Detail&, long int, const GA_PrimitiveDefinition&)}’ to ‘GA_PrimitiveBlockConstructor {aka void (*)(GA_Primitive**, long int, GA_Detail&, long int, const GA_PrimitiveDefinition&, bool)}’ [-fpermissive]
gu_newPrimVDB, GA_FAMILY_NONE);
Would you be able to take a look at syncing those files again? I'll then be able to configure Windows builds prior to Houdini 18.0.352 to use the local headers.
@ianww in the interim, if downloading and using Houdini 18.0.352 a suitable solution for you, give that a shot
I reran with the Houdini 18.0.352 daily build and those errors were gone! Excellent!
A couple of new LINK errors came up though, as shown here:
Error LNK2001 unresolved external symbol "__declspec(dllimport) int `public: __cdecl UT_WorkBuffer::~UT_WorkBuffer(void)'::`7'::ignore" (__imp_?ignore@?6???1UT_WorkBuffer@@QEAA@XZ@4HA) C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.vcxproj C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GEO_VDBTranslator.obj 1
Error LNK2019 unresolved external symbol "__declspec(dllimport) public: static class GU_PrimVDB * __cdecl GU_PrimVDB::buildFromGrid(class GU_Detail &,class std::shared_ptr<class openvdb::v7_0abi6::GridBase>,class GEO_PrimVDB const *,char const *)" (__imp_?buildFromGrid@GU_PrimVDB@@SAPEAV1@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v7_0abi6@openvdb@@@std@@PEBVGEO_PrimVDB@@PEBD@Z) referenced in function "class GU_PrimVDB * __cdecl openvdb_houdini::createVdbPrimitive(class GU_Detail &,class std::shared_ptr<class openvdb::v7_0abi6::GridBase>,char const *)" (?createVdbPrimitive@openvdb_houdini@@YAPEAVGU_PrimVDB@@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v7_0abi6@openvdb@@@std@@PEBD@Z) C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.vcxproj C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Utils.obj 1
In a similar way to the previous errors, I could trace the second error to buildFromGrid in GU_PrimVDB. I used a similar solution to what you'd done for the others in the daily build - I added SYS_FORCE_IN_LINE at line 120 of GU_PrimVDB.
That error disappeared with a rebuild, leaving just the first error.
Unfortunately, I can't work out what the first error means. It's clearly in UT_WorkBuffer.h but where I can't tell.
If you're planning another daily tomorrow I'll wait for that but if not I'd appreciate you telling me what to add where, and I'll give it a run before the next daily.
BTW - the files that made it into my release folders with this build attempt are:
and
The UT_WorkBuffer linker error is coming from the UT_ASSERT macro used in the destructor. It's not usually expected that client code builds with UT_ASSERT_LEVEL defined. To track this down where it's coming from, you can try adding this code to the top of UT_Assert.h
(just below the header guard)
#ifdef UT_ASSERT_LEVEL
#define UT_ASSERT_LEVEL bad
#endif
This should give a compiler warning about there it was first defined.
As for the GU_PrimVDB linker errors, I'll apply the same type of change I did for GEO_PrimVDB. Surprisingly, I haven't hit this yet. Not entirely sure what compiler settings vcpkg is using.
PS. Regarding -DSESI_OPENVDB_PRIM
, I've been increasingly of the opinion that it's a lost cause at this point.
PPS. I'm not entirely sure that the UT_WorkBuffer problem isn't a VS2019 bug though. I would have expected that the static ignore variable for a force-inlined method be generated in the same translation unit that's generating the inlined method.
The GU_PrimVDB.h inline accessors are now forced with SYS_STATIC_INLINE in Houdini 18.0.353.
I was hoping that I could mark these methods within the VDB copies of GEO/GU_PrimVDB and build with
-DSESI_OPENVDB_PRIM
but they seem to be out of sync. I've be able to fix most of the issues except for an error inGU_PrimVDB::registerMyself(GA_PrimitiveFactory *factory)
:Would you be able to take a look at syncing those files again? I'll then be able to configure Windows builds prior to Houdini 18.0.352 to use the local headers.
@Idclip I finally took a quick look at this and I see this commit message from H16.0.290 in the HDK's samples/tetprim/GEO_PrimTetra.C:
* Merge constructors are no more! Well, technically, the GA_PrimitiveDefinition::setMergeConstructor function still exists, but only for the deprecation warning message. This means that all primitive types can now be constructed in parallel... once HDK users update their primitive types.
This code path has been rotting for quite some time because it's only used for -DSESI_OPENVDB_PRIM
. So I think my suggestion here is to just remove the setMergeConstructor() call altogether. I've attached a patch of the differences between the 18.0 version of GU_PrimVDB and the one in openvdb_houdini.
Thanks @e4lam - I added:
#ifdef UT_ASSERT_LEVEL
#define UT_ASSERT_LEVEL bad
#endif
below the header guard of UT_Assert.h as you suggested but the error message is exactly the same.
The VS error report identifies file GEO_VDBTranslator.obj line 1 as where the error occurs -but perhaps that's just where the link attempt is occurring? (please excuse my limited knowledge!).
@ianww That's odd, did GEO_VDBTranslator.cc
get rebuilt after the change? I would expect that you get a compiler error when compiling that source file. It looks to me that it should somehow indirectly include UT_WorkBuffer.h and then UT_Assert.h judging from the linker error. You can also add #error HERE
lines to double-check whether the files are being seen by the compiler.
Yes, it seems to have been rebuilt - it has the same time-modified as the other files:
Both GEO_PrimVDB.obj
and GU_PrimVDB.obj
seem very small, as if they haven't built properly, even though their errors have gone.
Sorry, but I'm not sure where/how to add #error HERE
lines).
I note that the first non-comment line of GEO_VDBTranslator.cc
is #include "GU_PrimVDB.h"
, which is the file where the other (apparently fixed) error occurred, so maybe the two errors are related, and it's still something wrong back in GU_PrimVDB.h
?
When I was looking at that file to add in the edit that I did, I noticed that there were quite a few methods that didn't have SYS_FORCE_IN_LINE - maybe one or more of those still need to have it added in?
I went back to the beginning to check all my steps. In doing so I realised that vcpkg install boost-python
defaults to python3, and boost-python3.7 had therefore been installed. However, Houdini uses python2.7.
I therefore replaced boost-python3.7 with boost-python2.7 by changing vcpkg's boost-python CONTROL file to force vcpkg to bring in boost-python2.7 rather than 3.7.
Having done that, I regenerated the CMake cache and tried another build.
The bad news is that a whole lot more LINK errors (25 in total) have appeared. The good news is that this is because the build got much further on than it did previously.
Additional good news is that the odd ?1UT_WorkBuffer@@QEAA@XZ@4HA
error appears to have gone.
The old (boost-python3.7) build and new (boost-python2.7) build seem the same up to and including the first lot of code generation:
```
>------ Build started: Project: CMakeLists, Configuration: Release ------
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Checking Build System
Building Custom Rule C:/vcpkg/openvdb/openvdb/CMakeLists.txt
Grid.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Archive.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\Archive.cc(1085,1): warning C4996: 'getenv': This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdlib.h(1191): message : see declaration of 'getenv' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
Compression.cc
C:\vcpkg\openvdb\openvdb\io\Compression.cc(85,35): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\Compression.cc(213,34): warning C4146: unary minus operator applied to unsigned type, result still unsigned
DelayedLoadMetadata.cc
File.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\io\File.cc(74,1): warning C4996: 'getenv': This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdlib.h(1191): message : see declaration of 'getenv' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
GridDescriptor.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Queue.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
Stream.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
TempFile.cc
C:\vcpkg\openvdb\openvdb\io\TempFile.cc(100,1): warning C4996: 'tmpnam': This function or variable may be unsafe. Consider using tmpnam_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\stdio.h(440): message : see declaration of 'tmpnam' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb\openvdb_shared.vcxproj]
Maps.cc
Proximity.cc
QuantizedUnitVec.cc
Transform.cc
Metadata.cc
MetaMap.cc
openvdb.cc
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(112,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\util\NodeMasks.h(134,36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\math\Math.h(81,54): warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\vcpkg\openvdb\openvdb\..\openvdb/io/Compression.h(506): message : see reference to function template instantiation 'T openvdb::v7_0abi5::math::negative
Then the old build and new build outputs deviate. Here's the subsequent old output.
```
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GEO_VDBTranslator.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v7_0abi5@openvdb@@XZ) referenced in function "bool __cdecl `anonymous namespace'::fileSaveVDB
And here's the subsequent new output:
```
openvdb_houdini.vcxproj -> C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Release\openvdb_houdini.dll
Building Custom Rule C:/vcpkg/openvdb/openvdb_houdini/CMakeLists.txt
GR_PrimVDBPoints.cc
Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version.
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(214,1): warning C4273: 'GUI_PrimVDBPointsHook::createPrimitive': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(82,19): message : see previous definition of 'createPrimitive' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(338,5): warning C4273: 'GR_PrimVDBPoints::GR_PrimVDBPoints': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(98,5): message : see previous definition of '{ctor}' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(347,1): warning C4273: 'GR_PrimVDBPoints::acceptPrimitive': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(107,25): message : see previous definition of 'acceptPrimitive' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(434,1): warning C4273: 'GR_PrimVDBPoints::computeCentroid': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(138,10): message : see previous definition of 'computeCentroid' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(449,1): warning C4273: 'GR_PrimVDBPoints::computeBbox': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(139,10): message : see previous definition of 'computeBbox' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(534,1): warning C4273: 'GR_PrimVDBPoints::updatePosBuffer': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(141,10): message : see previous definition of 'updatePosBuffer' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(635,1): warning C4273: 'GR_PrimVDBPoints::updateWireBuffer': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(145,10): message : see previous definition of 'updateWireBuffer' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(718,1): warning C4273: 'GR_PrimVDBPoints::update': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(116,10): message : see previous definition of 'update' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(761,1): warning C4273: 'GR_PrimVDBPoints::inViewFrustum': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(120,10): message : see previous definition of 'inViewFrustum' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(778,1): warning C4273: 'GR_PrimVDBPoints::updateVec3Buffer': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(149,10): message : see previous definition of 'updateVec3Buffer' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(846,1): warning C4273: 'GR_PrimVDBPoints::updateVec3Buffer': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(155,10): message : see previous definition of 'updateVec3Buffer' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(860,1): warning C4273: 'GR_PrimVDBPoints::removeBuffer': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(160,10): message : see previous definition of 'removeBuffer' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(866,1): warning C4273: 'GR_PrimVDBPoints::render': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(130,10): message : see previous definition of 'render' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(939,1): warning C4273: 'GR_PrimVDBPoints::renderDecoration': inconsistent dll linkage
C:\vcpkg\openvdb\openvdb_houdini\GR_PrimVDBPoints.cc(135,10): message : see previous definition of 'renderDecoration' [C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.vcxproj]
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/GR_PrimVDBPoints.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/GR_PrimVDBPoints.exp
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi6::GridBase const * __cdecl GT_PrimVDB::getGrid(void)" (__imp_?getGrid@GT_PrimVDB@@QEAAPEBVGridBase@v7_0abi6@openvdb@@XZ) referenced in function "public: virtual void __cdecl GR_PrimVDBPoints::renderDecoration(class RE_Render *,enum GR_Decoration,class GR_DecorationParms const &)" (?renderDecoration@GR_PrimVDBPoints@@UEAAXPEAVRE_Render@@W4GR_Decoration@@AEBVGR_DecorationParms@@@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl GUI_PrimVDBPointsHook::GUI_PrimVDBPointsHook(void)" (__imp_??0GUI_PrimVDBPointsHook@@QEAA@XZ) referenced in function newRenderHook
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl GUI_PrimVDBPointsHook::~GUI_PrimVDBPointsHook(void)" (__imp_??1GUI_PrimVDBPointsHook@@UEAA@XZ) referenced in function "public: virtual void * __cdecl GUI_PrimVDBPointsHook::`scalar deleting destructor'(unsigned int)" (??_GGUI_PrimVDBPointsHook@@UEAAPEAXI@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl GR_PrimVDBPoints::~GR_PrimVDBPoints(void)" (__imp_??1GR_PrimVDBPoints@@UEAA@XZ) referenced in function "public: virtual void * __cdecl GR_PrimVDBPoints::`scalar deleting destructor'(unsigned int)" (??_GGR_PrimVDBPoints@@UEAAPEAXI@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl GR_PrimVDBPoints::className(void)const " (?className@GR_PrimVDBPoints@@UEBAPEBDXZ)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.obj : error LNK2001: unresolved external symbol "public: virtual int __cdecl GR_PrimVDBPoints::renderPick(class RE_Render *,class GR_DisplayOption const *,unsigned int,enum GR_PickStyle,bool)" (?renderPick@GR_PrimVDBPoints@@UEAAHPEAVRE_Render@@PEBVGR_DisplayOption@@IW4GR_PickStyle@@_N@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl GR_PrimVDBPoints::resetPrimitives(void)" (?resetPrimitives@GR_PrimVDBPoints@@UEAAXXZ)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) const GR_PrimVDBPoints::`vftable'" (__imp_??_7GR_PrimVDBPoints@@6B@) referenced in function "public: __cdecl GR_PrimVDBPoints::GR_PrimVDBPoints(class GR_RenderInfo const *,char const *,class GEO_Primitive const *)" (??0GR_PrimVDBPoints@@QEAA@PEBVGR_RenderInfo@@PEBDPEBVGEO_Primitive@@@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GR_PrimVDBPoints.dll : fatal error LNK1120: 8 unresolved externals
Building Custom Rule C:/vcpkg/openvdb/openvdb_houdini/CMakeLists.txt
SHOP_OpenVDB_Points.cc
Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version.
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SHOP_OpenVDB_Points.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SHOP_OpenVDB_Points.exp
SHOP_OpenVDB_Points.vcxproj -> C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SHOP_OpenVDB_Points.dll
Building Custom Rule C:/vcpkg/openvdb/openvdb_houdini/CMakeLists.txt
SOP_OpenVDB_Advect.cc
Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version.
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Advect.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Advect.exp
SOP_OpenVDB_Advect.vcxproj -> C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_OpenVDB_Advect.dll
Building Custom Rule C:/vcpkg/openvdb/openvdb_houdini/CMakeLists.txt
SOP_OpenVDB_Advect_Points.cc
Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version.
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Advect_Points.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Advect_Points.exp
SOP_OpenVDB_Advect_Points.vcxproj -> C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_OpenVDB_Advect_Points.dll
Building Custom Rule C:/vcpkg/openvdb/openvdb_houdini/CMakeLists.txt
SOP_OpenVDB_Analysis.cc
Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version.
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Analysis.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Analysis.exp
SOP_OpenVDB_Analysis.vcxproj -> C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_OpenVDB_Analysis.dll
Building Custom Rule C:/vcpkg/openvdb/openvdb_houdini/CMakeLists.txt
SOP_OpenVDB_Clip.cc
Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version.
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Clip.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Clip.exp
SOP_OpenVDB_Clip.vcxproj -> C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_OpenVDB_Clip.dll
Building Custom Rule C:/vcpkg/openvdb/openvdb_houdini/CMakeLists.txt
SOP_OpenVDB_Combine.cc
Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version.
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Combine.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Combine.exp
SOP_OpenVDB_Combine.vcxproj -> C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_OpenVDB_Combine.dll
Building Custom Rule C:/vcpkg/openvdb/openvdb_houdini/CMakeLists.txt
SOP_OpenVDB_Convert.cc
Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version.
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Convert.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/SOP_OpenVDB_Convert.exp
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_OpenVDB_Convert.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::shared_ptr
The new error listing is here:
```
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1125 (message):
New Boost version may have incorrect or missing dependencies and imported
targets C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.15/Modules/FindBoost.cmake 1125
Warning CMake Warning (dev) at C:/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package):
Policy CMP0074 is not set: find_package uses
Most of the new LINK errors relate to openvdb_houdini cc files (not Houdini h files as before).
LINK errors occur with these openvdb_houdini files:
GR_PrimVDBPoints
GUI_PrimVDBPointsHook (class within GR_PrimVDBPoints)
GEO_PrimVDB
SOP_OpenVDB_Convert
SOP_OpenVDB_Filter
SOP_OpenVDB_Filter_Level_Set
SOP_OpenVDB_From_Particles
SOP_OpenVDB_Potential_Flow
SOP_OpenVDB_Ray
SOP_OpenVDB_To_Polygons
SOP_OpenVDB_To_Spheres
There's also a cast error in VRAY_OpenVDB_Points
, which is also an openvdb_houdini file.
There's also a link error with GT_PrimVDB
, which is a Houdini file.
I'd appreciate your further thoughts!
@ianww I think that by starting from scratch, you've possibly now changed the goal posts. The GEO_PrimVDB::getGridPtr()
linker errors suggests that you're either now compiling with a GEO_PrimVDB.h where this method is not SYS_FORCE_INLINE or perhaps that the abi being used is now incompatible.
VS2019 is also a new compiler version that only the next (major) version of Houdini will be supporting. If possible, I would go back to using the latest compiler version in VS2017 instead.
Double-checking the openvdb version used in Houdini 18, it's OpenVDB 6.2.1. I don't know offhand if anyone has successfully tested a custom OpenVDB version that differed with Houdini's on Windows. From the above errors, it's complaining that v7 ABI symbols missing. It might very well be due to mixing usage of the Houdini openvdb headers with the separate openvdb headers during the build process.
I chose Visual Studio 2017 as the generator (from within Visual Studio 2019) and tried a rebuild - got all the same errors. So, it does seem that it's the ABI conflict issue.
I therefore dropped back to Houdini 17.5.425, using VS2017 as the generator.
Only 7 errors after that, from 4 unresolved externals:
Generating Code...
Creating library C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/Release/openvdb_houdini.lib and object C:/vcpkg/openvdb/out/build/x64-Release/openvdb_houdini/Release/openvdb_houdini.exp
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GEO_VDBTranslator.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v7_0abi5@openvdb@@XZ) referenced in function "bool __cdecl `anonymous namespace'::fileSaveVDB<class openvdb::v7_0abi5::io::File,char const *>(class GEO_Detail const *,char const *)" (??$fileSaveVDB@VFile@io@v7_0abi5@openvdb@@PEBD@?A0x709f137f@@YA_NPEBVGEO_Detail@@PEBD@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GT_GEOPrimCollectVDB.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v7_0abi5@openvdb@@XZ)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_NodeVDB.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v7_0abi5@openvdb@@XZ)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\PointUtils.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::shared_ptr<class openvdb::v7_0abi5::GridBase const > __cdecl GEO_PrimVDB::getConstGridPtr(void)const " (__imp_?getConstGridPtr@GEO_PrimVDB@@QEBA?AV?$shared_ptr@$$CBVGridBase@v7_0abi5@openvdb@@@std@@XZ) referenced in function "void __cdecl openvdb_houdini::`anonymous namespace'::sopBuildVDBPointsGroupMenu(void *,class PRM_Name *,int,class PRM_SpareData const *,class PRM_Parm const *)" (?sopBuildVDBPointsGroupMenu@?A0xd9fa97c0@openvdb_houdini@@YAXPEAXPEAVPRM_Name@@HPEBVPRM_SpareData@@PEBVPRM_Parm@@@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_NodeVDB.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v7_0abi5::GridBase & __cdecl GEO_PrimVDB::getGrid(void)" (__imp_?getGrid@GEO_PrimVDB@@QEAAAEAVGridBase@v7_0abi5@openvdb@@XZ) referenced in function "protected: virtual enum UT_ErrorSeverity __cdecl openvdb_houdini::SOP_NodeVDB::cookMyGuide1(class OP_Context &)" (?cookMyGuide1@SOP_NodeVDB@openvdb_houdini@@MEAA?AW4UT_ErrorSeverity@@AEAVOP_Context@@@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Utils.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class GU_PrimVDB * __cdecl GU_PrimVDB::buildFromGrid(class GU_Detail &,class std::shared_ptr<class openvdb::v7_0abi5::GridBase>,class GEO_PrimVDB const *,char const *)" (__imp_?buildFromGrid@GU_PrimVDB@@SAPEAV1@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v7_0abi5@openvdb@@@std@@PEBVGEO_PrimVDB@@PEBD@Z) referenced in function "class GU_PrimVDB * __cdecl openvdb_houdini::createVdbPrimitive(class GU_Detail &,class std::shared_ptr<class openvdb::v7_0abi5::GridBase>,char const *)" (?createVdbPrimitive@openvdb_houdini@@YAPEAVGU_PrimVDB@@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v7_0abi5@openvdb@@@std@@PEBD@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Release\openvdb_houdini.dll : fatal error LNK1120: 4 unresolved externals
All the errors appear to arise in GEO_PrimVDB,
at either getGrid
or getConstGridPtr.
I therefore tried editing Houdini 17.5.425's GEO_PrimVDB.h
file, by adding SYS_FORCE_INLINE
at line 654 and 666. However, all the above errors remained.
Unless my edits were the wrong thing to do (entirely possible), this seemed to leave the ABI conflict as the problem.
I therefore stepped back with all three elements - back to a combination of the VS2017 compiler, Houdini 17.5 and openvdb 6.2.0.
I tried a build and the result was just one solitary error!
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\LINK : fatal error LNK1181: cannot open input file 'C:\Program Files\Side Effects Software\Houdini 17.5.425\dsolib\libHoudiniRAY.so'
I may be wrong but I think libHoudiniRAY.so is a UNIX file, and the equivalent for Windows would be libHoudiniRAY.lib, so it seems something is mixed up.
To try to fix this, I made the #606 changes to OpenVDBHoudiniSetup.cmake suggested earlier by @Idclip for Houdini 18 in that file in Houdini 17 (although the line numbering was different).
I then tried a build, and...the above 7 LINK errors came back. Aaargggh! It's 2 am, and my brain's shot. I'll need to leave it for now.
I feel like I'm very close to a zero error build, however.
I'd be delighted if you could suggest a solution to this last stumble!
@ianww I'm trying to reproduce your steps but have you tried just telling vcpkg to build OpenVDB? Looking at the openvdb port, they have patches to the cmake files in OpenVDB.
I think I'm very close to getting rid of this one remaining error.
I've undone all the #606 changes I made to the Houdini 17.5 OpenVDBHoudiniSetup.cmake and replaced them with a reduced version, as follows.
Starting at line 200, I've replaced:
if(APPLE)
set(_HOUDINI_LIB_DIR
Frameworks/Houdini.framework/Versions/Current/Libraries
)
list(APPEND _HOUDINI_EXTRA_LIBRARIES
${_HOUDINI_LIB_DIR}/libHoudiniRAY.dylib
${_HOUDINI_LIB_DIR}/libhboost_regex.dylib
${_HOUDINI_LIB_DIR}/libhboost_thread.dylib
)
else()
set(_HOUDINI_LIB_DIR dsolib)
list(APPEND _HOUDINI_EXTRA_LIBRARIES
${_HOUDINI_LIB_DIR}/libHoudiniRAY.so
${_HOUDINI_LIB_DIR}/libhboost_regex.so
${_HOUDINI_LIB_DIR}/libhboost_thread.so
)
endif()
with:
if(APPLE)
set(_HOUDINI_LIB_DIR
Frameworks/Houdini.framework/Versions/Current/Libraries
)
list(APPEND _HOUDINI_EXTRA_LIBRARIES
${_HOUDINI_LIB_DIR}/libHoudiniRAY.dylib
${_HOUDINI_LIB_DIR}/libhboost_regex.dylib
${_HOUDINI_LIB_DIR}/libhboost_thread.dylib
)
elseif(UNIX)
set(_HOUDINI_LIB_DIR dsolib)
list(APPEND _HOUDINI_EXTRA_LIBRARIES
${HOUDINI_DSOLIB_DIR}/libHoudiniRAY.so
${HOUDINI_DSOLIB_DIR}/libhboost_regex.so
${HOUDINI_DSOLIB_DIR}/libhboost_thread.so
)
elseif(WIN32)
set(_HOUDINI_LIB_DIR dsolib)
list(APPEND _HOUDINI_EXTRA_LIBRARIES
#libRAY is already included by houdini for windows builds
${HOUDINI_DSOLIB_DIR}/hboost_regex-mt.lib
${HOUDINI_DSOLIB_DIR}/hboost_thread-mt.lib
)
endif()
This follows the principles of #606 but is just focused on my particular error. It deals with a Windows build explicitly.
When I try a build with this I still get one error but it's a different one. It's no longer referring to a missing libHoudiniRAY.so
, which is both a UNIX file and not necessary anyway with Windows because it's already included by Houdini for Windows builds.
The error is now just about the path to hboost_regex-mt.lib
:
LNK1181: cannot open input file 'C:\Program Files\Side Effects Software\Houdini 17.5.425\\hboost_regex-mt.lib'
The correct path to this file is actually:
C:\Program Files\Side Effects Software\Houdini 17.5.425\custom\houdini\dsolib\hboost_regex-mt.lib
The error seems to be that an escape backslash has slipped into the path. I haven't yet been able to work out where that's happened but I'll keep looking.
If anyone's able to point the location out to me I'd be grateful.
(BTW - I did try a vcpkg build openvdb
as you suggested and after a bit of fiddling I did get a successful CMake build for x86-Windows (but only without python). However, there were no obj files or make files or Visual Solution sln files created and I couldn't make sense of what to do next. I figured solving this last error with my current approach was less of a headache - at least I've developed a basic undrstanding of what I'm doing with that!)
The error is now just about the path to
hboost_regex-mt.lib
:LNK1181: cannot open input file 'C:\Program Files\Side Effects Software\Houdini 17.5.425\\hboost_regex-mt.lib'
The correct path to this file is actually:
C:\Program Files\Side Effects Software\Houdini 17.5.425\custom\houdini\dsolib\hboost_regex-mt.lib
The error seems to be that an escape backslash has slipped into the path. I haven't yet been able to work out where that's happened but I'll keep looking.
@ianww That error looks like ${HOUDINI_DSOLIB_DIR}
is wrong. They're in different locations on Windows owing to the fact that the actual shared libraries (.DLL
's) need to reside in the same directory as houdini.exe
so that PATH doesn't need to be modified. For code that builds against shared libraries on Windows, you need link them against "import libraries" (which are proxy libraries that know how load the .DLL that it was built from) instead. And that's why these .lib's are in a different location within the installation.
I've undone all the #606 changes I made to the Houdini 17.5 OpenVDBHoudiniSetup.cmake and replaced them with a reduced version, as follows.
I'm a bit confused as to why you've done this? The issue you're now facing is fixed in the entire #606 PR (the dso lib path for windows). I'll be merging this soon.
@e4lam thanks for the patch, I'm going to try and apply that soon. Note that the cmake patches in the vcpkg seem to be irrelevant for the issues we're encountering (and I have no idea why some of them are even required at all...).
To clarify, here's a list what we've discovered:
/Zc:externC-
compile option for the openvdb houdini build (in VS 2019 16.0 only?)SYS_FORCE_INLINE
methods in the Houdini headers (in VS 2019 16.0 only?)-DSESI_OPENVDB_PRIM
There's something about putting all the #606 edits in that throws it back to the unresolved external errors. I've just tried it again - I did the full #606 edits to the Houdini 17.5 OpenVDBHoudiniSetup.cmake file. The line numbering is different to that shown in #606 for Houdini 18, so I could have made some silly error. I'll recheck again but for now, with the full #606 edits, I return to these errors:
C:\vcpkg\openvdb - close to success\out\build\x64-Release\openvdb_houdini\GEO_VDBTranslator.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v6_2abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v6_2abi5@openvdb@@XZ) referenced in function "bool __cdecl `anonymous namespace'::fileSaveVDB<class openvdb::v6_2abi5::io::File,char const *>(class GEO_Detail const *,char const *)" (??$fileSaveVDB@VFile@io@v6_2abi5@openvdb@@PEBD@?A0x5761416f@@YA_NPEBVGEO_Detail@@PEBD@Z)
C:\vcpkg\openvdb - close to success\out\build\x64-Release\openvdb_houdini\GT_GEOPrimCollectVDB.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class openvdb::v6_2abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v6_2abi5@openvdb@@XZ)
C:\vcpkg\openvdb - close to success\out\build\x64-Release\openvdb_houdini\SOP_NodeVDB.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class openvdb::v6_2abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v6_2abi5@openvdb@@XZ)
C:\vcpkg\openvdb - close to success\out\build\x64-Release\openvdb_houdini\PointUtils.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::shared_ptr<class openvdb::v6_2abi5::GridBase const > __cdecl GEO_PrimVDB::getConstGridPtr(void)const " (__imp_?getConstGridPtr@GEO_PrimVDB@@QEBA?AV?$shared_ptr@$$CBVGridBase@v6_2abi5@openvdb@@@std@@XZ) referenced in function "void __cdecl openvdb_houdini::`anonymous namespace'::sopBuildVDBPointsGroupMenu(void *,class PRM_Name *,int,class PRM_SpareData const *,class PRM_Parm const *)" (?sopBuildVDBPointsGroupMenu@?A0x501ac16b@openvdb_houdini@@YAXPEAXPEAVPRM_Name@@HPEBVPRM_SpareData@@PEBVPRM_Parm@@@Z)
C:\vcpkg\openvdb - close to success\out\build\x64-Release\openvdb_houdini\SOP_NodeVDB.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v6_2abi5::GridBase & __cdecl GEO_PrimVDB::getGrid(void)" (__imp_?getGrid@GEO_PrimVDB@@QEAAAEAVGridBase@v6_2abi5@openvdb@@XZ) referenced in function "protected: virtual enum UT_ErrorSeverity __cdecl openvdb_houdini::SOP_NodeVDB::cookMyGuide1(class OP_Context &)" (?cookMyGuide1@SOP_NodeVDB@openvdb_houdini@@MEAA?AW4UT_ErrorSeverity@@AEAVOP_Context@@@Z)
C:\vcpkg\openvdb - close to success\out\build\x64-Release\openvdb_houdini\Utils.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class GU_PrimVDB * __cdecl GU_PrimVDB::buildFromGrid(class GU_Detail &,class std::shared_ptr<class openvdb::v6_2abi5::GridBase>,class GEO_PrimVDB const *,char const *)" (__imp_?buildFromGrid@GU_PrimVDB@@SAPEAV1@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v6_2abi5@openvdb@@@std@@PEBVGEO_PrimVDB@@PEBD@Z) referenced in function "class GU_PrimVDB * __cdecl openvdb_houdini::createVdbPrimitive(class GU_Detail &,class std::shared_ptr<class openvdb::v6_2abi5::GridBase>,char const *)" (?createVdbPrimitive@openvdb_houdini@@YAPEAVGU_PrimVDB@@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v6_2abi5@openvdb@@@std@@PEBD@Z)
C:\vcpkg\openvdb - close to success\out\build\x64-Release\openvdb_houdini\Release\openvdb_houdini.dll : fatal error LNK1120: 4 unresolved externals
With the reduced version, I only get the single path error:
LNK1181: cannot open input file 'C:\Program Files\Side Effects Software\Houdini 17.5.425\\hboost_regex-mt.lib'
It's weird - the #606 logic seems impeccable but it's doing this.
I'll go back through my edits and recheck, and recheck...
I'm doing an x64 build - should the #606 edits actually be elseif(win32 || win64)
?
If so, HOUDINI_DSOLIB_DIR
would have been undefined for me.
With the reduced version, I only get the single path error:
That's because it's not even managing to reach the stage that the #606 fixes get you to. You'll end up getting the same linker errors. I'll take a look at those additional errors as soon as possible
I'm doing an x64 build - should the #606 edits actually be elseif(win32 || win64) ?
win64 is not a valid cmake define. https://cmake.org/cmake/help/latest/variable/WIN32.html
BTW - in my CMake settings I have Houdini_DIR
set to:
C:/Program Files/Side Effects Software/Houdini 17.5.425
I hope that's right. I've also tried:
C:\Program Files\Side Effects Software\Houdini 17.5.425\custom\houdini
but that didn't help.
I've also tried it with these variables variously ON and OFF:
USE-DEFAULT_HOUDINI_INSTALL
USE_SYSTEM_LIBRARY_PATHS
I'm scratching around a bit here...but could it be the use of forward slashes in windows path names? I note further up in the file double back slashes are used for win (while forward are used for linux and osx):
if(_houdini_platform_linux)
set(_instdir $ENV{HOME}/houdini${_houdini_release_version})
elseif(_houdini_platform_osx)
set(_instdir $ENV{HOME}/Library/Preferences/houdini/${_houdini_release_version})
elseif(_houdini_platform_win)
set(_instdir $ENV{HOMEDRIVE}$ENV{HOMEPATH}\\Documents\\houdini${_houdini_release_version})
Something I've noticed -
In each of these LINK errors:
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GEO_VDBTranslator.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v6_2abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v6_2abi5@openvdb@@XZ) referenced in function "bool __cdecl `anonymous namespace'::fileSaveVDB<class openvdb::v6_2abi5::io::File,char const *>(class GEO_Detail const *,char const *)" (??$fileSaveVDB@VFile@io@v6_2abi5@openvdb@@PEBD@?A0x709f137f@@YA_NPEBVGEO_Detail@@PEBD@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GT_GEOPrimCollectVDB.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class openvdb::v6_2abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v6_2abi5@openvdb@@XZ)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_NodeVDB.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class openvdb::v6_2abi5::GridBase const & __cdecl GEO_PrimVDB::getGrid(void)const " (__imp_?getGrid@GEO_PrimVDB@@QEBAAEBVGridBase@v6_2abi5@openvdb@@XZ)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\PointUtils.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::shared_ptr<class openvdb::v6_2abi5::GridBase const > __cdecl GEO_PrimVDB::getConstGridPtr(void)const " (__imp_?getConstGridPtr@GEO_PrimVDB@@QEBA?AV?$shared_ptr@$$CBVGridBase@v6_2abi5@openvdb@@@std@@XZ) referenced in function "void __cdecl openvdb_houdini::`anonymous namespace'::sopBuildVDBPointsGroupMenu(void *,class PRM_Name *,int,class PRM_SpareData const *,class PRM_Parm const *)" (?sopBuildVDBPointsGroupMenu@?A0xd9fa97c0@openvdb_houdini@@YAXPEAXPEAVPRM_Name@@HPEBVPRM_SpareData@@PEBVPRM_Parm@@@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\SOP_NodeVDB.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class openvdb::v6_2abi5::GridBase & __cdecl GEO_PrimVDB::getGrid(void)" (__imp_?getGrid@GEO_PrimVDB@@QEAAAEAVGridBase@v6_2abi5@openvdb@@XZ) referenced in function "protected: virtual enum UT_ErrorSeverity __cdecl openvdb_houdini::SOP_NodeVDB::cookMyGuide1(class OP_Context &)" (?cookMyGuide1@SOP_NodeVDB@openvdb_houdini@@MEAA?AW4UT_ErrorSeverity@@AEAVOP_Context@@@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Utils.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class GU_PrimVDB * __cdecl GU_PrimVDB::buildFromGrid(class GU_Detail &,class std::shared_ptr<class openvdb::v6_2abi5::GridBase>,class GEO_PrimVDB const *,char const *)" (__imp_?buildFromGrid@GU_PrimVDB@@SAPEAV1@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v6_2abi5@openvdb@@@std@@PEBVGEO_PrimVDB@@PEBD@Z) referenced in function "class GU_PrimVDB * __cdecl openvdb_houdini::createVdbPrimitive(class GU_Detail &,class std::shared_ptr<class openvdb::v6_2abi5::GridBase>,char const *)" (?createVdbPrimitive@openvdb_houdini@@YAPEAVGU_PrimVDB@@AEAVGU_Detail@@V?$shared_ptr@VGridBase@v6_2abi5@openvdb@@@std@@PEBD@Z)
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\Release\openvdb_houdini.dll : fatal error LNK1120: 4 unresolved externals
the paths to the obj files are (for example):
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GEO_VDBTranslator.obj
but looking for these obj files on my machine they are actually at (same example):
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.dir\Release\GEO_VDBTranslator.obj
My CMAKE_INSTALL_PREFIX is set to C:\vcpkg\openvdb\out\build\x64-Release
Maybe LINK is expecting to find the obj's in:
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini
but can't because for some reason the build has actually put them in:
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini.dir\Release
The corresponding h files on my machine are in:
C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\openvdb_houdini
which is probably also not what LINK would be expecting.
EDIT: I've since realised/worked out that C:\vcpkg\openvdb\out\build\x64-Release\openvdb_houdini\GEO_VDBTranslator.obj
is not where CMake is finding GEO_VDBTranslator.obj
but rather where it is trying to build it to, and that ...\openvdb_houdini.dir
is an intermediate directory in that build process. So, the error is more fundamental than a simple path error.
To clarify, here's a list what we've discovered:
@Idclip Thanks for this because this and the other thread is quite lot of stuff to sift through and I admit that I've been too lazy to read them in detail.
* Required `/Zc:externC-` compile option for the openvdb houdini build (in VS 2019 16.0 only?)
I assume that this is for Boost.Interprocess (discussed here https://developercommunity.visualstudio.com/content/problem/756694/including-windowsh-and-boostinterprocess-headers-l.html ) ? I've been struggling with the Boost.Interprocess issues myself because clang-cl behaves the same now and has no option to do /Zc:externC-
. In my builds, I've locally added -DBOOST_USE_WINDOWS_H
to work around the issue. There's a whole whack of other changes in my local repo to mostly get clang-cl working, some of which has duplicated the work done to get VS2019 going.
* Missing `SYS_FORCE_INLINE` methods in the Houdini headers (in VS 2019 16.0 only?) * Issues with using the optional Houdini headers deployed with VDB `-DSESI_OPENVDB_PRIM`
Hopefully these issues should be resolved with the latest GU_PrimVDB.h/GEO_PrimVDB.h changes.
As for the remaining linking issues, I'm not sure why we're still running into those because those should have SYS_FORCE_INLINE now. Unless, the /Zc:externC-
is doing than what we want it to.
FYI - I don't think add_compile_options(/Zc:externC-)
is doing anything when compiling with Visual Studio 2017 because I get a warning D9002: ignoring unknown option '/Zc:externC-'
@ianww Yes, sorry, I should have mentioned that. In the visualstudio.com link, it discusses when this option started becoming necessary in VS2019.
Another thought: My default CMake advanced variables settings include:
CMAKE_CXX_FLAGS /DWIN32 /D_WINDOWS /W3 /GR /EHsc
CMAKE_CXX_FLAGS_RELEASE /MD /O2 /Ob2 /DNDEBUG
CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO
CMAKE_MODULE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO
Are these correct?
I'm trying to build openvdb against Houdini in Windows 10, using vcpkg (and then Visual Studio 2019).
I've run into the same error, which I haven't been able to resolve:
Firstly, it seems odd that it says "found suitable version" when it's also saying "could not find" it.
Also, inside C:\vcpkg\installed\x64-windows\lib I can see Half:
So, it seems that it's there but CMake just can't find it. I get the same error even if I explicitly point to this lib directory with my CMake command:
I've been making a guide document for myself as I go, which I've attached to show the detail of what I've done so far. OpenVDB installation using vcpkg - github query.pdf
In summary, my steps have been:
If I run vcpkg list, it shows that ilmbase is installed:
I've cloned the openvdb git:
My CMake command in Windows Powershell is:
I'm wondering if the error is because CMake is expecting to find Half in a discrete ilmbase libary but Half is now actually built inside OpenEXR, which the empty ilmbase package should be pointing to but isn't.
I'd really appreciate some guidance on resolving this!
Originally posted by @ianww in https://github.com/AcademySoftwareFoundation/openvdb/issues/429#issuecomment-571989625