VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2023-04-24T16:34:46-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/18567Build failure when building thirdparty mpi4py2023-04-24T16:34:46-04:00Jack·Boos·YuBuild failure when building thirdparty mpi4pyHi guys,
Recently I'm trying to build vtk with internal module mpi4py (https://github.com/microsoft/vcpkg/pull/24740), but I got some failures:
```
FAILED: ThirdParty/mpi4py/vtkmpi4py/src/CMakeFiles/vtkmpi4py.MPI.dir/MPI.c.obj
C:\PROGRA...Hi guys,
Recently I'm trying to build vtk with internal module mpi4py (https://github.com/microsoft/vcpkg/pull/24740), but I got some failures:
```
FAILED: ThirdParty/mpi4py/vtkmpi4py/src/CMakeFiles/vtkmpi4py.MPI.dir/MPI.c.obj
C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1432~1.313\bin\Hostx64\x64\cl.exe -DMPICH_SKIP_MPICXX -DMPI_NO_CPPBIND -DOMPI_SKIP_MPICXX -DPyMPI_MISSING_MPI_Status_c2f -DPyMPI_MISSING_MPI_Status_f2c -DPyMPI_MISSING_MPI_Type_create_f90_complex -DPyMPI_MISSING_MPI_Type_create_f90_integer -DPyMPI_MISSING_MPI_Type_create_f90_real -DVTK_IN_VTK -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_MPICC_H -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -Dvtkmpi4py_MPI_EXPORTS -ID:\buildtrees\vtk\x64-windows-dbg\Utilities\Python -ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Utilities\Python -ID:\buildtrees\vtk\x64-windows-dbg\Common\Core -ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Common\Core -external:ID:\buildtrees\vtk\x64-windows-dbg\Utilities\MPI -external:ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Utilities\MPI -external:ID:\installed\x64-windows\include -external:ID:\buildtrees\vtk\x64-windows-dbg\Utilities\KWIML -external:ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Utilities\KWIML -external:ID:\buildtrees\vtk\x64-windows-dbg\Utilities\KWSys -external:ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Utilities\KWSys -external:ID:\installed\x64-windows\include\python3.10 -external:W0 /nologo /DWIN32 /D_WINDOWS /W3 /utf-8 /MP /bigobj /D_DEBUG /MDd /Z7 /Ob0 /Od /RTC1 -MDd /showIncludes /FoThirdParty\mpi4py\vtkmpi4py\src\CMakeFiles\vtkmpi4py.MPI.dir\MPI.c.obj /FdThirdParty\mpi4py\vtkmpi4py\src\CMakeFiles\vtkmpi4py.MPI.dir\ /FS -c D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\MPI.c
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154210): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154212): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154500): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154502): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154880): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154882): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155076): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155078): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155263): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155265): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155459): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155461): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155678): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155680): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155848): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155850): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(156863): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(156865): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157169): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157171): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157439): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157441): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157612): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157614): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(174420): warning C4996: '_PyUnicode_get_wstr_length': deprecated in 3.3
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(174436): warning C4996: '_PyUnicode_get_wstr_length': deprecated in 3.3
```
Then I searched the same issue by google, and I found the workaround is:
```patch
diff --git a/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c b/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c
index d01c266..9983ac9 100644
--- a/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c
+++ b/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c
@@ -154207,9 +154207,9 @@ static void __pyx_tp_dealloc_6mpi4py_3MPI_Datatype(PyObject *o) {
{
PyObject *etype, *eval, *etb;
PyErr_Fetch(&etype, &eval, &etb);
- ++Py_REFCNT(o);
+ Py_SET_REFCNT(o, Py_REFCNT(o) + 1);
__pyx_pw_6mpi4py_3MPI_8Datatype_3__dealloc__(o);
- --Py_REFCNT(o);
+ Py_SET_REFCNT(o, Py_REFCNT(o) - 1);
PyErr_Restore(etype, eval, etb);
}
(*Py_TYPE(o)->tp_free)(o);
```
It seems that the problem is caused by the wrong version of cpython (or python? maybe).
And I found the mpi4py was updated to 3.1.3 now: https://github.com/mpi4py/mpi4py/tree/master.
Any ideas on this issue?
Thanks,
JackBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18552Error when mpi is not selected after installing hdf5[parallel]2022-05-30T03:34:31-04:00Jack·Boos·YuError when mpi is not selected after installing hdf5[parallel]Hi guys,
I'm vcpkg maintainer.
Recently we received an issue about vtk build issues: https://github.com/microsoft/vcpkg/pull/24740.
The issue is:
When you first install hdf5 including feature parallel, and use it as a dependency of vt...Hi guys,
I'm vcpkg maintainer.
Recently we received an issue about vtk build issues: https://github.com/microsoft/vcpkg/pull/24740.
The issue is:
When you first install hdf5 including feature parallel, and use it as a dependency of vtk to install vtk that does not select mpi as a feature, an error will be reported:
```
-- VTK module debug building: VTK::hdf5 is being built
-- Checking for module 'mpi-c'
-- Package 'mpi-c', required by 'virtual:world', not found
-- Checking for module 'mpi-cxx'
-- Package 'mpi-cxx', required by 'virtual:world', not found
CMake Error at ThirdParty/hdf5/CMakeLists.txt:21 (message):
An external MPI-aware HDF5 requires that VTK be built with MPI support as
well.
```
In vcpkg and other package management, dependencies should be forward: if I select a feature in a downstream library, the upstream library should be asked to select the corresponding feature; not that if the upstream library enables a feature, the downstream library must be enabled a corresponding feature.
This has a disastrous effect on dependencies.
What do you guys think about?
How can we "fix" this issue?
Thanks,
Jackhttps://gitlab.kitware.com/vtk/vtk/-/issues/18514libvtkhdf5 contains unmangled symbols2022-04-19T06:49:53-04:00Menno Deij - van Rijswijklibvtkhdf5 contains unmangled symbolsWhen I build paraview with HDF5 coming from VTK/ThirdParty/hdf5, the resulting libvtkhdf5-pv10.so contains many unmangled symbols starting with H5. For example `H5D_def_layout_chunk_g`, which I also find in a build-from-vanilla-source li...When I build paraview with HDF5 coming from VTK/ThirdParty/hdf5, the resulting libvtkhdf5-pv10.so contains many unmangled symbols starting with H5. For example `H5D_def_layout_chunk_g`, which I also find in a build-from-vanilla-source libhdf5.so shared library.
I thought the idea was that no symbol clashes between a loaded vanilla libhdf5 and the libvtkhdf5 shared libraries could occur, thereby enabling another code to have libhdf5 loaded, and also load libvtkhdf5 (maybe as part of in-situ processing) and not have symbols clashing, leading to unpredictable behavior, especially when the two libraries have different versions.
For reference, find attached the results of
`nm libvtkhdf5-pv5.10.so | grep \ vtkhdf5 > libvtkhdf5-mangled.txt`
[libvtkhdf5-mangled.txt](/uploads/b95b058546fa9581bda3a0e6c4678515/libvtkhdf5-mangled.txt)
and `nm libvtkhdf5-pv5.10.so | grep \ H5 > libvtkhdf5-unmangled.txt`
[libvtkhdf5-unmangled.txt](/uploads/48d9e94dd28127b1fb579a2ac3c12fe9/libvtkhdf5-unmangled.txt)
Maybe I'm going about this the wrong way, and this is not a problem.
@utkarsh.ayachit I hope it is OK if I assign this to you, I saw some MR's that also related to symbol mangling of HDF5 with your name on it.Jaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/18512vtk_module_compile_options does not behave exactly like target_compile_options2022-04-15T21:03:12-04:00Mathieu Westphal (Kitware)vtk_module_compile_options does not behave exactly like target_compile_options`vtk_module_compile_options(target PUBLIC PRIVATE)` fails with:
```
target_compile_options called with incorrect number of arguments
```
While
target_compile_options(target PUBLIC PRIVATE) works without issue.
The problem is that ...`vtk_module_compile_options(target PUBLIC PRIVATE)` fails with:
```
target_compile_options called with incorrect number of arguments
```
While
target_compile_options(target PUBLIC PRIVATE) works without issue.
The problem is that during the argument processing in vtk_module_compile_options, if none are provided, the resulting call is:
`target_compile_options(target)`, which is incorrect.
This is highly impractical with these kind of codes:
```
vtk_module_compile_options(target PUBLIC ${ACCUMULATED_PUBLIC_OPTIONS} PRIVATE ${ACCUMULATED_PRIVATE_OPTIONS} )
```
@ben.boeckel9.2Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18506VTKDetermineVersion.cmake bug2022-07-25T16:39:30-04:00olesenVTKDetermineVersion.cmake bugCompiling a git version of paraview with the various submodules.
VTKDetermineVersion.cmake (Line 64) reports that it detected a VTK git version v5.10.1-884-gefeaf2c2c5 but has a hardcoded version of 9.1.xyz.
It appears to be running _g...Compiling a git version of paraview with the various submodules.
VTKDetermineVersion.cmake (Line 64) reports that it detected a VTK git version v5.10.1-884-gefeaf2c2c5 but has a hardcoded version of 9.1.xyz.
It appears to be running _git describe_ from one directory below where it should be.9.2Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18487Configuration error with CMake 3.142022-07-26T21:03:11-04:00Sergey KlevtsovConfiguration error with CMake 3.14Apologies if this has been reported, issue search did not reveal anything.
When trying to configure latest release (9.1.0) with CMake 3.14, the following error occurs (full log is attached):
```
CMake Error at /usr/local/share/cmake-3.1...Apologies if this has been reported, issue search did not reveal anything.
When trying to configure latest release (9.1.0) with CMake 3.14, the following error occurs (full log is attached):
```
CMake Error at /usr/local/share/cmake-3.14/Modules/FindPackageHandleStandardArgs.cmake:195 (message):
Unknown keywords given to FIND_PACKAGE_HANDLE_STANDARD_ARGS():
"REASON_FAILURE_MESSAGE"
Call Stack (most recent call first):
CMake/patches/3.22/FindMPI.cmake:1823 (find_package_handle_standard_args)
CMake/vtkModule.cmake:4397 (find_package)
CMake/vtkModule.cmake:4997 (vtk_module_find_package)
Utilities/MPI/CMakeLists.txt:1 (vtk_module_third_party_external)
-- Configuring incomplete, errors occurred!
```
The error is caused by the following line, which uses a new CMake 3.16 keyword `REASON_FAILURE_MESSAGE`: https://gitlab.kitware.com/vtk/vtk/-/blob/d79e2977b601db1e0592c02b1536f39b6b367314/CMake/patches/3.22/FindMPI.cmake#L1826
The error did not occur in 9.0.3. The change was introduced in https://gitlab.kitware.com/vtk/vtk/-/commit/6343855027c54bed98183d5b4001f02eb1c1b705.
[vtk-9.1.0-cmake-3.14-configure.txt](/uploads/4f9288c4c08a5cba0fa8e5b5d20bbf97/vtk-9.1.0-cmake-3.14-configure.txt)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18449vtk9.1.0 Emscripten build failed with proj.db and sqlite32023-11-01T10:39:22-04:00勇闯天涯啦vtk9.1.0 Emscripten build failed with proj.db and sqlite3I try to build the vtk-9.1.0 with Emscripten&&CLang follow the cmake-setting propose by [dicehub](https://github.com/dicehub/EmVTK) and [issues/18263](https://gitlab.kitware.com/vtk/vtk/-/issues/18263). But I met the error below.
```
...I try to build the vtk-9.1.0 with Emscripten&&CLang follow the cmake-setting propose by [dicehub](https://github.com/dicehub/EmVTK) and [issues/18263](https://gitlab.kitware.com/vtk/vtk/-/issues/18263). But I met the error below.
```
[1/214] Generating proj.db
FAILED: share/vtk-9.1/proj/proj.db
C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/share/vtk-9.1/proj/proj.db
cmd.exe /C "cd /D C:\DevTools\vtksource\VTK-9.1.0\Examples\Emscripten\Cxx\work\src\ThirdParty\libproj\vtklibproj\data && "C:\Program Files\CMake\bin\cmake.exe" -E remove -f C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/lib/../share/vtk-9.1/proj/proj.db && "C:\Program Files\CMake\bin\cmake.exe" -DALL_SQL_IN=C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/ThirdParty/libproj/vtklibproj/data/all.sql.in -DEXE_SQLITE3=C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/bin/sqlitebin-9.1.js -DPROJ_DB=C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/lib/../share/vtk-9.1/proj/proj.db -DPROJ_VERSION=8.1.0 -P C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/src/ThirdParty/libproj/vtklibproj/data/generate_proj_db.cmake && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/lib/../share/vtk-9.1/proj/proj.db C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/ThirdParty/libproj/vtklibproj/data/for_tests"
CMake Error at generate_proj_db.cmake:22 (message):
SQLite3 failed
[2/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/horner.cpp.o
[3/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/xyzgridshift.cpp.o
[4/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/molodensky.cpp.o
[5/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/deformation.cpp.o
[6/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/hgridshift.cpp.o
[7/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/vgridshift.cpp.o
[8/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/iso19111/metadata.cpp.o
[9/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/tinshift.cpp.o
[10/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/defmodel.cpp.o
ninja: build stopped: subcommand failed.
```
here is my cmake-setting:
```
cmake \
-G Ninja \
-DCMAKE_TOOLCHAIN_FILE=C:/DevTools/emsdk/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake \
-DBUILD_SHARED_LIBS=OFF \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_EXAMPLES:BOOL=OFF \
-DBUILD_TESTING:BOOL=OFF \
-DVTK_ENABLE_LOGGING=OFF \
-DVTK_ENABLE_WRAPPING=OFF \
-DVTK_GROUP_ENABLE_Imaging=NO \
-DVTK_GROUP_ENABLE_MPI=NO \
-DVTK_GROUP_ENABLE_Qt=NO \
-DVTK_GROUP_ENABLE_Rendering=WANT \
-DVTK_GROUP_ENABLE_StandAlone=WANT \
-DVTK_GROUP_ENABLE_Views=NO \
-DVTK_GROUP_ENABLE_Web=NO \
-DVTK_LEGACY_REMOVE=ON \
-DVTK_NO_PLATFORM_SOCKETS=ON \
-DVTK_MODULE_ENABLE_VTK_hdf5=NO \
-DVTK_MODULE_ENABLE_VTK_InteractionStyle=WANT \
-DVTK_MODULE_ENABLE_VTK_InteractionWidgets=WANT \
-DVTK_MODULE_ENABLE_VTK_RenderingContext2D=DONT_WANT \
-DVTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2=DONT_WANT \
-DOPENGL_INCLUDE_DIR:PATH=C:/DevTools/emsdk/upstream/emscripten/system/include \
-DOPENGL_EGL_INCLUDE_DIR:PATH=C:/DevTools/emsdk/upstream/emscripten/system/include \
-DOPENGL_GLES2_INCLUDE_DIR:PATH=C:/DevTools/emsdk/upstream/emscripten/system/include \
-DOPENGL_GLES3_INCLUDE_DIR:PATH=C:/DevTools/emsdk/upstream/emscripten/system/include \
-DVTK_OPENGL_USE_GLES:BOOL=ON \
-DVTK_USE_SYSTEM_FREETYPE:BOOL=ON \
-DH5_HAVE_GETPWUID:BOOL=OFF \
-DFREETYPE_INCLUDE_DIRS:PATH='include' \
-DFREETYPE_LIBRARY:STRING='freetype' \
C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/src
cmake --build .
```
where did it go wrong?https://gitlab.kitware.com/vtk/vtk/-/issues/18445Build failure with ffmpeg-5.02022-03-28T16:36:20-04:00BerndBuild failure with ffmpeg-5.0The current v9 releases of VTK won't build their IOFFMPEG module, against an installed ffmpeg-5.0 package. We received a bug report on Gentoo on this for 9.0.3. I tested with 9.1.0 which fails as well.
The error is
```
FAILED: IO/FFMPEG...The current v9 releases of VTK won't build their IOFFMPEG module, against an installed ffmpeg-5.0 package. We received a bug report on Gentoo on this for 9.0.3. I tested with 9.1.0 which fails as well.
The error is
```
FAILED: IO/FFMPEG/CMakeFiles/IOFFMPEG.dir/vtkFFMPEGWriter.cxx.o
/usr/bin/mpicxx -DIOFFMPEG_EXPORTS -DVTK_IN_VTK -D__STDC_CONSTANT_MACROS -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/IO/FFMPEG -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/IO/Movie -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/Movie -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/ExecutionModel -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/ExecutionModel -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/Core -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/Core -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/DataModel -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/DataModel -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/Math -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/Math -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/Transforms -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/Transforms -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/IO/Video -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/Video -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/Misc -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/Misc -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/System -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/System -isystem /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Utilities/KWIML -isystem /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Utilities/KWIML -isystem /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Utilities/KWSys -isystem /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Utilities/KWSys -O2 -march=native -fomit-frame-pointer -pipe -fvisibility-inlines-hidden -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -std=c++11 -MD -MT IO/FFMPEG/CMakeFiles/IOFFMPEG.dir/vtkFFMPEGWriter.cxx.o -MF IO/FFMPEG/CMakeFiles/IOFFMPEG.dir/vtkFFMPEGWriter.cxx.o.d -o IO/FFMPEG/CMakeFiles/IOFFMPEG.dir/vtkFFMPEGWriter.cxx.o -c /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx
/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx: In member function ‘int vtkFFMPEGWriterInternal::Start()’:
/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx:111:41: error: invalid conversion from ‘const AVOutputFormat*’ to ‘AVOutputFormat*’ [-fpermissive]
111 | this->avOutputFormat = av_guess_format("avi", nullptr, nullptr);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
| |
| const AVOutputFormat*
/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx:137:37: error: invalid conversion from ‘const AVCodec*’ to ‘AVCodec*’ [-fpermissive]
137 | if (!(codec = avcodec_find_encoder(this->avOutputFormat->video_codec)))
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| const AVCodec*
/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx:152:32: error: ‘avcodec_alloc_context3’ was not declared in this scope; did you mean ‘avio_alloc_context’?
```
with more errors after that and similar errors later on in file `vtkFFMPEGVideoSource.cxx`.
See also https://bugs.gentoo.org/831595 with a full build log attached.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18429FindPython support uses `cmake_path()` which it should not2022-01-08T20:03:11-05:00David ThompsonFindPython support uses `cmake_path()` which it should notThe CMake support for finding python uses the `cmake_path()` command. This command was introduced in cmake 3.20 which causes problems when build VTK with older versions of cmake. See here
https://gitlab.kitware.com/vtk/vtk/-/blob/1cae65...The CMake support for finding python uses the `cmake_path()` command. This command was introduced in cmake 3.20 which causes problems when build VTK with older versions of cmake. See here
https://gitlab.kitware.com/vtk/vtk/-/blob/1cae6585c3015d754c72f545be983e0e41e6ca17/CMake/patches/3.23/FindPython/Support.cmake#L3053-3055
for the 2 places it is used.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18413OpenVDBWriter constructor segfaults with openVDB 92023-12-06T11:45:15-05:00Antonio RojasOpenVDBWriter constructor segfaults with openVDB 9This minimal example
```
#include <vtk/vtkOpenVDBWriter.h>
int main() {
vtkOpenVDBWriter* a=vtkOpenVDBWriter::New();
}
```
segfaults with openVDB 9 with this backtrace:
```
(gdb) bt
#0 openvdb::v9_0::Grid<openvdb::v9_0::tree::Tree<...This minimal example
```
#include <vtk/vtkOpenVDBWriter.h>
int main() {
vtkOpenVDBWriter* a=vtkOpenVDBWriter::New();
}
```
segfaults with openVDB 9 with this backtrace:
```
(gdb) bt
#0 openvdb::v9_0::Grid<openvdb::v9_0::tree::Tree<openvdb::v9_0::tree::RootNode<openvdb::v9_0::tree::InternalNode<openvdb::v9_0::tree::InternalNode<openvdb::v9_0::tree::LeafNode<openvdb::v9_0::ValueMask, 3u>, 4u>, 5u> > > >::gridType[abi:cxx11]()
() at /usr/src/debug/openvdb-9.0.0/openvdb/openvdb/Grid.h:719
#1 openvdb::v9_0::Grid<openvdb::v9_0::tree::Tree<openvdb::v9_0::tree::RootNode<openvdb::v9_0::tree::InternalNode<openvdb::v9_0::tree::InternalNode<openvdb::v9_0::tree::LeafNode<openvdb::v9_0::ValueMask, 3u>, 4u>, 5u> > > >::registerGrid ()
at /usr/src/debug/openvdb-9.0.0/openvdb/openvdb/Grid.h:981
#2 openvdb::v9_0::initialize () at /usr/src/debug/openvdb-9.0.0/openvdb/openvdb/openvdb.cc:100
#3 0x00007ffff7e1da25 in vtkOpenVDBWriter::vtkOpenVDBWriter (this=0x55555558a050)
at /usr/src/debug/VTK-9.1.0/IO/OpenVDB/vtkOpenVDBWriter.cxx:365
#4 0x00007ffff7e1dabe in vtkOpenVDBWriter::New () at /usr/src/debug/VTK-9.1.0/IO/OpenVDB/vtkOpenVDBWriter.cxx:357
#5 0x0000555555555166 in main ()
```https://gitlab.kitware.com/vtk/vtk/-/issues/18379VTK 9.1.0 does not compile with Qt52022-01-10T05:28:03-05:00Billy AraujoVTK 9.1.0 does not compile with Qt5GUISupport/QtQuick/QQuickVTKInteractorAdapter.cxx does not compile with Qt5.11.2.
```
//-------------------------------------------------------------------------------------------------
void QQuickVTKInteractorAdapter::QueueWheelEvent(...GUISupport/QtQuick/QQuickVTKInteractorAdapter.cxx does not compile with Qt5.11.2.
```
//-------------------------------------------------------------------------------------------------
void QQuickVTKInteractorAdapter::QueueWheelEvent(QQuickItem* item, QWheelEvent* e)
{
QPointF p, gp;
#if QT_VERSION >= QT_VERSION_CHECK(5, 14, 0)
p = e->position();
gp = e->globalPosition();
#else
p = e->posF();
gp = e->globalPosF();
#endif
QWheelEvent* newEvent = new QWheelEvent(this->mapEventPosition(item, p),
this->mapEventPosition(item, gp), e->pixelDelta(), e->angleDelta(), e->buttons(),
e->modifiers(), e->phase(), e->inverted(), e->source());
QueueEvent(newEvent);
}
```
This seems to only work for Qt 6 as this is the signature of the new constructor.
`QWheelEvent(const QPointF &pos, const QPointF &globalPos, QPoint pixelDelta, QPoint angleDelta, Qt::MouseButtons buttons, Qt::KeyboardModifiers modifiers, Qt::ScrollPhase phase, bool inverted, Qt::MouseEventSource source = Qt::MouseEventNotSynthesized, const QPointingDevice *device = QPointingDevice::primaryPointingDevice())`
In Qt 5 it was:
`QWheelEvent(const QPointF &pos, const QPointF &globalPos, QPoint pixelDelta, QPoint angleDelta, int qt4Delta, Qt::Orientation qt4Orientation, Qt::MouseButtons buttons, Qt::KeyboardModifiers modifiers, Qt::ScrollPhase phase, Qt::MouseEventSource source, bool inverted)`
So I doubt this compiles on any Qt5 version. All VTK compiles on Qt5 except for this line so this should be fixed as many people are not using Qt6.
Also shouldn't this type of thing be caught by the CI system? Doesn't it build and test with Qt5 and Qt6?https://gitlab.kitware.com/vtk/vtk/-/issues/18343Config failure for python static build2021-10-28T18:10:25-04:00David GobbiConfig failure for python static buildOn ubuntu 20.04, the following config gives an error for the current release head:
```bash
cmake -G Ninja ../vtk-gitlab -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF \
-DVTK_BUILD_TESTING=OFF -DVTK_PYTHON_VERSION=3 -DVTK_WRAP...On ubuntu 20.04, the following config gives an error for the current release head:
```bash
cmake -G Ninja ../vtk-gitlab -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF \
-DVTK_BUILD_TESTING=OFF -DVTK_PYTHON_VERSION=3 -DVTK_WRAP_PYTHON=ON
```
```text
CMake Error at CMake/vtkModuleWrapPython.cmake:987 (target_link_libraries):
INTERFACE library can only be used with the INTERFACE keyword of
target_link_libraries
```
The cmake code in question:
```cmake
if (_vtk_python_UTILITY_TARGET)
target_link_libraries("${_vtk_python_TARGET_NAME}"
PRIVATE
"${_vtk_python_UTILITY_TARGET}")
endif ()
```
Tested with cmake 3.16.3 and with 3.21, both produced the same error.9.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18310H5detect vs H5Tinit.c dependency problem2021-09-23T15:32:40-04:00David GobbiH5detect vs H5Tinit.c dependency problemSystem: macOS 10.15, cmake 3.13.2, GNU make 3.81, VTK master from Sept 15, 2021
Doing a "Makefile" build (-j 1) of VTK generated this error:
```text
No rule to make target 'ThirdParty/hdf5/vtkhdf5/src/H5Tinit.c'
```
The build continued ...System: macOS 10.15, cmake 3.13.2, GNU make 3.81, VTK master from Sept 15, 2021
Doing a "Makefile" build (-j 1) of VTK generated this error:
```text
No rule to make target 'ThirdParty/hdf5/vtkhdf5/src/H5Tinit.c'
```
The build continued after I forced H5detect to build:
```bash
make H5detect
make
```
I haven't dug very deep into this, but the following code block [(line 1084 in ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt)](https://gitlab.kitware.com/vtk/vtk/-/blob/7591e63b/ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt#L1084) seems to be implicated:
```cmake
add_custom_command (TARGET H5detect POST_BUILD
COMMAND ${CMAKE_CROSSCOMPILING_EMULATOR} $<TARGET_FILE:H5detect>
ARGS H5Tinit.c
BYPRODUCTS H5Tinit.c gen_SRCS.stamp1
COMMAND ${CMAKE_COMMAND}
ARGS -E touch gen_SRCS.stamp1
DEPENDS H5detect
WORKING_DIRECTORY ${HDF5_GENERATED_SOURCE_DIR}
COMMENT "Create H5Tinit.c"
)
```
Perhaps the problem is the use of "BYPRODUCTS" with no "OUTPUT" with the Makefile generator?
There seem to be similar dependency issues with `H5lib_settings.c` and `H5make_libsettings`. In that case, the workaround was this:
```
make H5make_libsettings
```Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18296compilation fails with stable fmt2021-09-13T02:41:51-04:00Julien Schuellercompilation fails with stable fmtwith gcc compilation fails with external fmt 8.0.1 (VTK_MODULE_USE_EXTERNAL_VTK_fmt=OFF)
```
vtkPVStringFormatter.h:153:9: error: use of deleted function ‘fmt::v8::dynamic_format_arg_store<fmt::v8::basic_format_context<fmt::v8::appender,...with gcc compilation fails with external fmt 8.0.1 (VTK_MODULE_USE_EXTERNAL_VTK_fmt=OFF)
```
vtkPVStringFormatter.h:153:9: error: use of deleted function ‘fmt::v8::dynamic_format_arg_store<fmt::v8::basic_format_context<fmt::v8::appender, char> >::dynamic_format_arg_store(const fmt::v8::dynamic_format_arg_store<fmt::v8::basic_format_context<fmt::v8::appender, char> >&)’
153 | : Args(args.Args)
| ^~~~~~~~~~~~~~~
```
is this a known issue ? is this an upstream issue ? seems the bundled one is some git version
cc @cory.quammen as you updated it lasthttps://gitlab.kitware.com/vtk/vtk/-/issues/18291Newest FindMPI incompatible with cmake < 3.182021-08-30T16:46:51-04:00David GobbiNewest FindMPI incompatible with cmake < 3.18The FindMPI patch in !8322 causes config errors with cmake 3.16 when `VTK_USE_MPI` is enabled:
```
CMake error at CMakeFiles/CMakeTmp/CMakeLists.txt:20 (target_link_libraries):
Error evaluating generator expression:
$<HOST_LINK:SHE...The FindMPI patch in !8322 causes config errors with cmake 3.16 when `VTK_USE_MPI` is enabled:
```
CMake error at CMakeFiles/CMakeTmp/CMakeLists.txt:20 (target_link_libraries):
Error evaluating generator expression:
$<HOST_LINK:SHELL:-pthread>
Expression did not evaluate to a known generator expression
CMake Error at CMake/patches/3.22/FindMPI.cmake:1266 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMake/patches/3.22/FindMPI.cmake:1317 (_MPI_try_staged_settings)
CMake/patches/3.22/FindMPI.cmake:1607 (_MPI_check_lang_works)
CMake/vtkModule.cmake:4360 (find_package)
CMake/vtkModule.cmake:4960 (vtk_module_find_package)
Utilities/MPI/CMakeLists.txt:1 (vtk_module_third_party_external)
```
Currently, VTK is targeting compatibility with cmake 3.12 and above.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18265Fails to build against HDF5 1.12.12021-08-26T07:57:47-04:00Bruno PaganiFails to build against HDF5 1.12.1There is a build failure when building against HDF5 1.12.1 that comes from https://gitlab.kitware.com/vtk/vtk/-/blob/master/ThirdParty/xdmf3/vtkxdmf3/core/XdmfHDF5Controller.hpp.
I’ve opened an issue at https://gitlab.kitware.com/xdmf/x...There is a build failure when building against HDF5 1.12.1 that comes from https://gitlab.kitware.com/vtk/vtk/-/blob/master/ThirdParty/xdmf3/vtkxdmf3/core/XdmfHDF5Controller.hpp.
I’ve opened an issue at https://gitlab.kitware.com/xdmf/xdmf/-/issues/28, hopefully this is the correct way for this kind of issues.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18226gitlab-ci: harmonize with other Kitware project setups2021-05-28T15:25:57-04:00Ben Boeckelgitlab-ci: harmonize with other Kitware project setupsThe CI setup in VTK-m is slightly different from other Kitware projects. Of particular note, the machine setup is completely different. It is getting more and more difficult to maintain the machines since they have all kinds of exception...The CI setup in VTK-m is slightly different from other Kitware projects. Of particular note, the machine setup is completely different. It is getting more and more difficult to maintain the machines since they have all kinds of exceptions on them. We (@brad.king and I) would like to reinstall these machines and sync them up with the rest of our machine setups:
- [ ] abeth
- [ ] renar
- [ ] umbra
In addition, there are machines still running buildbot jobs:
- [ ] dragnipur
- [ ] osheim
that would be also end up being reinstalled (though their other builds would need converted into CI jobs, mainly DIY).
Also of note is that macOS and Windows machines *only* contain:
- Git installation (with `git-lfs`)
- macOS only
- Xcode (macOS only)
- Windows only
- Visual Studio (and relevant toolchains)
- CUDA/NVIDIA drivers
- `sccache` binaries
- MSMPI (if needed for a project)
Everything else (including CMake and `ninja`) should be downloaded during the CI job so as to avoid having to juggle lots of software installation across many eligible machines.
Full task list:
- Use existing CI machines for existing CI jobs
- [ ] requires using [the same tagging strategy](https://gitlab.kitware.com/utils/ci-base-images/-/blob/master/doc/tags.md) used on the rest of the fleet
- Linux
- [ ] add NVIDIA hardware tags to existing machines
- [ ] disable VTK-m Linux runners to ensure jobs work on the temporary machines
- [ ] reinstall VTK-m Linux CI machines
- Add temporary runners for macOS and Windows to existing machines
- macOS
- [ ] `tunja`
- Windows
- [ ] `bop`
- [ ] `pol`
- Migrate Buildbot configurations to CI jobs
- [ ] `dragnipur-release` (macOS)
- [ ] `dragnipur-debug` (macOS)
- [ ] `osheim-release` (Windows)
- [ ] `osheim-debug` (Windows)
Cc: @vboleahttps://gitlab.kitware.com/vtk/vtk/-/issues/18208Keep track of why modules are provided/requested/rejected/etc.2021-05-12T08:19:29-04:00Ben BoeckelKeep track of why modules are provided/requested/rejected/etc.The module system should track why modules are enabled, provided, rejected, etc. for use in error messages. Currently this information is visible through debug flags and logging, but the error messages are a bit lost as to the actual rea...The module system should track why modules are enabled, provided, rejected, etc. for use in error messages. Currently this information is visible through debug flags and logging, but the error messages are a bit lost as to the actual reasons behind things.
Cc: @cory.quammenBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18144VTK::FiltersCorePython-QuadricDecimation2 test exclusion2021-09-02T21:03:13-04:00Ben BoeckelVTK::FiltersCorePython-QuadricDecimation2 test exclusionThe `VTK::FiltersCorePython-QuadricDecimation2` test is currently excluded on Windows CI. See the failure [here](https://open.cdash.org/test/360245245). The test passed on the CI Windows branch based off of 64c97df4874be90b63e5fad4350928...The `VTK::FiltersCorePython-QuadricDecimation2` test is currently excluded on Windows CI. See the failure [here](https://open.cdash.org/test/360245245). The test passed on the CI Windows branch based off of 64c97df4874be90b63e5fad43509284de6d97026, so presumably something in that range is to blame.
Cc: @cory.quammenBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18130Fails to build with PROJ 8.0.0 (proj_api.h removed)2021-03-13T18:35:44-05:00Bas CouwenbergFails to build with PROJ 8.0.0 (proj_api.h removed)Follow up to #17554.
VTK fails to build with PROJ 8.0.0 which has removed `proj_api.h`.
While suppport for `proj.h` has been added, `proj_api.h` is also still used:
```c
#if VTK_MODULE_USE_EXTERNAL_vtklibproj
# if VTK_LibPROJ_MAJOR_VER...Follow up to #17554.
VTK fails to build with PROJ 8.0.0 which has removed `proj_api.h`.
While suppport for `proj.h` has been added, `proj_api.h` is also still used:
```c
#if VTK_MODULE_USE_EXTERNAL_vtklibproj
# if VTK_LibPROJ_MAJOR_VERSION >= 5
# include <proj.h>
# endif
# if VTK_LibPROJ_MAJOR_VERSION < 6
# include <projects.h>
# endif
# if VTK_LibPROJ_MAJOR_VERSION >= 6
# define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H 1
# endif
# include <proj_api.h>
# include <geodesic.h>
#else
# include <vtklibproj/src/projects.h>
# include <vtklibproj/src/proj_api.h>
# include <vtklibproj/src/geodesic.h>
#endif
```
Restricting this to only use `proj.h` shows that the code still relies on `proj_api.h` features and has not been properly ported to the PROJ 6 API:
```cmake
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx: In destructor 'virtual vtkGeoProjection::~vtkGeoProjection()':
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx:124:5: error: 'pj_free' was not declared in this scope; did you mean 'free'?
124 | pj_free(this->Projection);
| ^~~~~~~
| free
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx: In member function 'virtual int vtkGeoProjection::UpdateProjection()':
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx:188:5: error: 'pj_free' was not declared in this scope; did you mean 'free'?
188 | pj_free(this->Projection);
| ^~~~~~~
| free
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx:194:24: error: 'pj_init_plus' was not declared in this scope
194 | this->Projection = pj_init_plus(this->PROJ4String);
| ^~~~~~~~~~~~
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx:234:24: error: 'pj_init' was not declared in this scope; did you mean 'u_int'?
234 | this->Projection = pj_init(argSize, const_cast<char**>(pjArgs));
| ^~~~~~~
| u_int
make[4]: *** [Geovis/Core/CMakeFiles/GeovisCore.dir/build.make:111: Geovis/Core/CMakeFiles/GeovisCore.dir/vtkGeoProjection.cxx.o] Error 1
```
The following patch was used to test the build with PROJ 8.0.0:
```patch
--- a/ThirdParty/libproj/vtk_libproj.h.in
+++ b/ThirdParty/libproj/vtk_libproj.h.in
@@ -32,10 +32,10 @@
# if VTK_LibPROJ_MAJOR_VERSION < 6
# include <projects.h>
# endif
-# if VTK_LibPROJ_MAJOR_VERSION >= 6
+# if VTK_LibPROJ_MAJOR_VERSION >= 6 && VTK_LibPROJ_MAJOR_VERSION < 8
# define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H 1
+# include <proj_api.h>
# endif
-# include <proj_api.h>
# include <geodesic.h>
#else
# include <vtklibproj/src/projects.h>
```