VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2020-04-02T19:47:55-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/17826SOABI detection is incorrect on Windows2020-04-02T19:47:55-04:00Ben BoeckelSOABI detection is incorrect on WindowsPer @federico.miorelli in https://gitlab.kitware.com/vtk/vtk/-/issues/17816#note_720667
> I will add that when using this mechanism, the name of the pyd files that are generated is vtkCommonCore.None.pyd
Cc: @marc.chevrierPer @federico.miorelli in https://gitlab.kitware.com/vtk/vtk/-/issues/17816#note_720667
> I will add that when using this mechanism, the name of the pyd files that are generated is vtkCommonCore.None.pyd
Cc: @marc.chevrier9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/178229.0.0rc1: Issue with DeepCopy on vtkUnstructuredGrid2020-04-14T07:34:54-04:00Peter Franz9.0.0rc1: Issue with DeepCopy on vtkUnstructuredGridHi,
I have an issue with a particular vtkUnstructuredGrid which appears to get corrupted when using DeepCopy:
vtkSmartPointer<vtkXMLUnstructuredGridReader> reader = vtkSmartPointer<vtkXMLUnstructuredGridReader>::New();
rea...Hi,
I have an issue with a particular vtkUnstructuredGrid which appears to get corrupted when using DeepCopy:
vtkSmartPointer<vtkXMLUnstructuredGridReader> reader = vtkSmartPointer<vtkXMLUnstructuredGridReader>::New();
reader->SetFileName("VoronoiCells.vtu");
reader->Update();
vtkSmartPointer<vtkUnstructuredGrid> ug = vtkSmartPointer<vtkUnstructuredGrid>::New();
ug->DeepCopy(reader->GetOutput());
vtkSmartPointer<vtkXMLUnstructuredGridWriter> writer = vtkSmartPointer<vtkXMLUnstructuredGridWriter>::New();
writer->SetInputData(ug);
writer->SetFileName("VoronoiCells-after-deepcopy.vtu");
writer->Update();
I will attach the specific grid VoronoiCells.vtu for which the corruption happens.
I'll also attach screenshots from paraview for the original file and the output from the corrupted file.
[VoronoiCells-after-deepcopy.vtu](/uploads/2c3afe8572a01e53b33a63ccb8e1405c/VoronoiCells-after-deepcopy.vtu)
[VoronoiCells.vtu](/uploads/c988908796fd3ce9f572e8690c3de0de/VoronoiCells.vtu)![VoronoiCells](/uploads/473c5ba5101c38c1cb8d027448945bf4/VoronoiCells.png)
![VoronoiCells-after-deepcopy](/uploads/262c8eae7cd55f63e268b5de5beb3715/VoronoiCells-after-deepcopy.png)9.0T.J. CoronaT.J. Coronahttps://gitlab.kitware.com/vtk/vtk/-/issues/178219.0.0rc1: Don't insist in having wrapper tools compiled if they are not used2020-04-01T13:59:32-04:00Jürgen Fuhrmann9.0.0rc1: Don't insist in having wrapper tools compiled if they are not usedHi
I am building vtk without HDF5, MPI, wrapper tools and need to cross-compile. VTK CMake still insists in having the compile tools installed when compiling with a toolchain file, creating some headaches. Is there a way to not configur...Hi
I am building vtk without HDF5, MPI, wrapper tools and need to cross-compile. VTK CMake still insists in having the compile tools installed when compiling with a toolchain file, creating some headaches. Is there a way to not configure compile tools in this case?
In fact I am trying to set up a Julia package VTKMinimal_jll.jl
This is the cmake command.
```
cmake -C DefaultTryRunResults.cmake\
-DVTK_CUSTOM_LIBRARY_SUFFIX=""\
-DCMAKE_REQUIRE_LARGE_FILE_SUPPORT=0\
-DBUILD_SHARED_LIBS=ON\
-DVTK_GROUP_ENABLE_Rendering=YES\
-DVTK_GROUP_ENABLE_StandAlone=YES\
-DVTK_GROUP_ENABLE_Imaging=NO\
-DVTK_GROUP_ENABLE_MPI=NO\
-DVTK_GROUP_ENABLE_Qt=NO\
-DVTK_GROUP_ENABLE_Views=NO\
-DVTK_GROUP_ENABLE_Web=NO\
-DVTK_MODULE_ENABLE_VTK_AcceleratorsVTKm:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_InfovisBoost:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_InfovisBoostGraphAlgorithms:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_InfovisCore:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_InfovisLayout:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_TestingCore:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_TestingGenericBridge:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_TestingIOSQL:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_TestingRendering:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_UtilitiesBenchmarks:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_DomainsChemistry:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_DomainsChemistryOpenGL2:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_DomainsMicroscopy:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_DomainsParallelChemistry:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_GeovisCore:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_GeovisGDAL:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingOpenVR:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingMatplotlib:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingParallel:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingParallelLIC:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingQt:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingVtkJS:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingRayTracing:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingSceneGraph:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_RenderingVolumeAMR:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_FiltersParallelMPI:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_ViewsInfovis:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_ChartsCore:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_FiltersAMR:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_h5part:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_hdf5:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOADIOS2:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOAMR:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOAsynchronous:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOCityGML:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOCore:STRING=DEFAULT\
-DVTK_MODULE_ENABLE_VTK_IOEnSight:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOExodus:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOExport:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOExportGL2PS:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOExportPDF:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOFFMPEG:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOGDAL:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOGeoJSON:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOGeometry:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOH5part:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOImage:STRING=DEFAULT\
-DVTK_MODULE_ENABLE_VTK_IOImport:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOInfovis:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOLAS:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOLSDyna:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOLegacy:STRING=DEFAULT\
-DVTK_MODULE_ENABLE_VTK_IOMINC:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOMPIImage:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOMPIParallel:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOMotionFX:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOMovie:STRING=DEFAULT\
-DVTK_MODULE_ENABLE_VTK_IOMySQL:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IONetCDF:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOODBC:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOOggTheora:STRING=DEFAULT\
-DVTK_MODULE_ENABLE_VTK_IOPDAL:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOPIO:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOPLY:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOParallel:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOParallelExodus:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOParallelLSDyna:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOParallelNetCDF:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOParallelXML:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOParallelXdmf3:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOPostgreSQL:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOSQL:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOSegY:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOTRUCHAS:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOTecplotTable:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOVPIC:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOVeraOut:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOVideo:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOXML:STRING=DEFAULT\
-DVTK_MODULE_ENABLE_VTK_IOXMLParser:STRING=DEFAULT\
-DVTK_MODULE_ENABLE_VTK_IOXdmf2:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_IOXdmf3:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_WrappingPythonCore:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_WrappingTools:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_PythonInterpreter:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_pegtl:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_sqlite:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_verdict:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_FiltersParallelVerdict:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_FiltersVerdict:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_verdict:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_vpic:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_vtkDICOM:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_xdmf2:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_xdmf3:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_zfp:STRING=NO\
-DVTK_MODULE_ENABLE_VTK_vtkm:STRING=NO\
-DVTK_MODULE_USE_EXTERNAL_VTK_glew:BOOL=ON\
-DVTK_MODULE_USE_EXTERNAL_VTK_zlib:BOOL=ON\
-DVTK_MODULE_USE_EXTERNAL_VTK_jpeg:BOOL=ON\
-DVTK_MODULE_USE_EXTERNAL_VTK_tiff:BOOL=ON\
-DVTK_MODULE_USE_EXTERNAL_VTK_freetype:BOOL=ON\
-DVTK_MODULE_USE_EXTERNAL_VTK_expat:BOOL=ON\
-DVTK_MODULE_USE_EXTERNAL_VTK_lz4:BOOL=ON\
-DVTK_MODULE_USE_EXTERNAL_VTK_lzma:BOOL=ON\
-DVTK_MODULE_USE_EXTERNAL_VTK_png:BOOL=ON\
-DVTKCompileTools_DIR=$prefix/lib64/cmake/vtkcompiletools-9.0\
-DCMAKE_INSTALL_PREFIX=$prefix\
-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TARGET_TOOLCHAIN}\
-DCMAKE_BUILD_TYPE=Release\
../VTK-9.0.0.rc1/
´´´9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17816VTK Wheel not working in Python3.82020-04-02T15:01:13-04:00ThiagoVTK Wheel not working in Python3.8Hi,
I've downloaded the VTK using git. I have the last commit (118d20aacadff5e3bba489d1ebb422f7858c72ca). I'm configuring and generating the Wheel this way:
```
cmake -GNinja -DVTK_BUILD_DOCUMENTATION=OFF -DVTK_BUILD_EXAMPLES=OFF -DBUI...Hi,
I've downloaded the VTK using git. I have the last commit (118d20aacadff5e3bba489d1ebb422f7858c72ca). I'm configuring and generating the Wheel this way:
```
cmake -GNinja -DVTK_BUILD_DOCUMENTATION=OFF -DVTK_BUILD_EXAMPLES=OFF -DBUILD_SHARED_LIBS=ON -DOpenGL_GL_PREFERENCE=GLVND -DVTK_USE_TK=OFF -DVTK_WRAP_JAVA=OFF -DVTK_WRAP_PYTHON=ON -DVTK_PYTHON_VERSION:STRING=3 -DVTK_WHEEL_BUILD=ON -DVTK_WRAP_TCL=OFF -DVTK_USE_CUDA=ON -DCMAKE_BUILD_TYPE=Release ../vtk/
ninja
python3 setup.py bdist_wheel
pip3 install ./dist/vtk-9.0.0-cp38-cp38-linux_x86_64.whl
```
I'm installing the wheel inside a virtualenv. When I try to import vtk that error that happens:
```
$ python
Python 3.8.2 (default, Mar 13 2020, 10:14:16)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vtk
Traceback (most recent call last):
File "/home/thiago/.virtualenvs/vtk90/lib/python3.8/site-packages/vtkmodules/__init__.py", line 13, in <module>
from . import vtkCommonCore
ImportError: cannot import name 'vtkCommonCore' from partially initialized module 'vtkmodules' (most likely due to a circular import) (/home/thiago/.virtualenvs/vtk90/lib/python3.8/site-packages/vtkmodules/__init__.py)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/thiago/.virtualenvs/vtk90/lib/python3.8/site-packages/vtk.py", line 30, in <module>
all_m = importlib.import_module('vtkmodules.all')
File "/home/thiago/.virtualenvs/vtk90/lib/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "/home/thiago/.virtualenvs/vtk90/lib/python3.8/site-packages/vtkmodules/__init__.py", line 15, in <module>
import _vtkmodules_static
ModuleNotFoundError: No module named '_vtkmodules_static
```9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17811FindNetCDF.cmake creates an unusable namespaced library2020-03-25T21:03:11-04:00Kyle BentleyFindNetCDF.cmake creates an unusable namespaced libraryI am using the CMake module for NetCDF in a different project, and I found what may be a small oversight in the CMake section of the NetCDF module provided by VTK.
Colleagues and myself were noticing that with the new release of netCDF,...I am using the CMake module for NetCDF in a different project, and I found what may be a small oversight in the CMake section of the NetCDF module provided by VTK.
Colleagues and myself were noticing that with the new release of netCDF, 4.7.3, that the namespaced version of the library, NetCDF::NetCDF, caused linking errors. It took us a moment to realize that while that imported target has the correct library name - netCDF, it doesn't provide any path information. This caused a situation where our build would find the locally compiled netCDF library, by name, but at link time would find an older system library in /usr/lib that didn't have the newer symbols. This happened even when using target_link_directories explicitly. When we hardcode the path to the correct library, all works as expected.
We were able to temporarily work around the issue by using the exported target netCDF_LIB_DIR from the lib/cmake/*config, and altering the target properties on the namespace to be SHARED instead of INTERFACE, and providing an IMPORTED_LOCATION based on the libname, and the netCDF_LIB_DIR above. The code below shows the changes we made (roughly). Is this an appropriate approach? I'm fairly well-versed in CMake, but I feel as if I'm missing something, or that it's not quite working as intended, compared to similarly namespaced targets. It'll work for us, on a single machine, but otherwise it goes against the 'create relocatable package' guidelines from CMake.
Any advice? Is there a way to get the path information using the Module as-is? Thanks in advance.
Old Section of code
```
# Try to find a CMake-built NetCDF.
find_package(netCDF CONFIG QUIET)
if (netCDF_FOUND)
# Forward the variables in a consistent way.
set(NetCDF_FOUND "${netCDF_FOUND}")
set(NetCDF_INCLUDE_DIRS "${netCDF_INCLUDE_DIR}")
set(NetCDF_LIBRARIES "${netCDF_LIBRARIES}")
set(NetCDF_VERSION "${NetCDFVersion}")
if (NOT TARGET NetCDF::NetCDF)
add_library(NetCDF::NetCDF INTERFACE IMPORTED)
set_target_properties(NetCDF::NetCDF PROPERTIES
INTERFACE_LINK_LIBRARIES "${NetCDF_LIBRARIES}")
endif ()
# Skip the rest of the logic in this file.
return ()
endif ()
```
New section of code
```
# Try to find a CMake-built NetCDF.
find_package(netCDF CONFIG QUIET)
if (netCDF_FOUND)
# Forward the variables in a consistent way.
set(NetCDF_FOUND "${netCDF_FOUND}")
set(NetCDF_INCLUDE_DIRS "${netCDF_INCLUDE_DIR}")
set(NetCDF_LIBRARIES "${netCDF_LIBRARIES}")
set(NetCDF_VERSION "${NetCDFVersion}")
set(NetCDF_LIBRARY_DIR "${netCDF_LIB_DIR}") <------------------- New
if (NOT TARGET NetCDF::NetCDF)
add_library(NetCDF::NetCDF SHARED IMPORTED) <------------------- Changed
set_target_properties(NetCDF::NetCDF PROPERTIES <------------------- Changed
IMPORTED_LOCATION "${NetCDF_LIBRARY_DIR}"/lib"${NetCDF_LIBRARIES}".so)
endif ()
# Skip the rest of the logic in this file.
return ()
endif ()
```9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17810python wheel created on OS X leads to broken python module2020-03-20T13:34:45-04:00Noam Bernsteinpython wheel created on OS X leads to broken python moduleI'm trying to use the wheel creation process in the current master (pre-9.0) with macports python 3.8.2. There's also an ongoing discussion at [text](https://discourse.vtk.org/t/python-3-8-wheel-on-mac-os-x/2850/7). I can enable `VTK_BU...I'm trying to use the wheel creation process in the current master (pre-9.0) with macports python 3.8.2. There's also an ongoing discussion at [text](https://discourse.vtk.org/t/python-3-8-wheel-on-mac-os-x/2850/7). I can enable `VTK_BUILD_WHEEL` in cmake, compile, and do `python setup.py bdist_wheel` apparently successfully, but the resulting wheel leads to a broken module. When I try to `import vtk`, I get
```>>> import vtk
Traceback (most recent call last):
File "/Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtkmodules/__init__.py", line 13, in <module>
from . import vtkCommonCore
ImportError: dlopen(/Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtkmodules/vtkCommonCore.cpython-38-darwin.so, 2): Library not loaded: @rpath/libvtkWrappingPythonCore.1.dylib
Referenced from: /Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtkmodules/vtkCommonCore.cpython-38-darwin.so
Reason: image not found
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtk.py", line 30, in <module>
all_m = importlib.import_module('vtkmodules.all')
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "/Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtkmodules/__init__.py", line 15, in <module>
import _vtkmodules_static
ModuleNotFoundError: No module named '_vtkmodules_static'
```
If I add `$HOME/Library/Python/3.8/lib/python/site-packages/vtkmodule` to DYLD_LIBRARY_PATH it works, suggesting to me that the libraries are not in the expected place (either in the wrong place, or not correctly indicating to python or the dyld loader where they are).9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17804Add wheel building docs to build.md instructions2020-03-25T21:03:11-04:00Ben BoeckelAdd wheel building docs to build.md instructionsInstructions for how to build a wheel are not included in the build documentation.
Cc: @tjcoronaInstructions for how to build a wheel are not included in the build documentation.
Cc: @tjcorona9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17776VTK/Common/Core/vtkLogger.h:487:69: error: format not a string literal and no...2020-04-02T21:03:13-04:00Orion PoplawskiVTK/Common/Core/vtkLogger.h:487:69: error: format not a string literal and no format arguments [-Werror=format-security]While trying to build paraview 5.8.0-RC1 on Fedora Rawhide:
```
In file included from /builddir/build/BUILD/ParaView-v5.8.0-RC1/VTK/GUISupport/Qt/QVTKRenderWindowAdapter.cxx:20:
/builddir/build/BUILD/ParaView-v5.8.0-RC1/VTK/GUISupport/Qt...While trying to build paraview 5.8.0-RC1 on Fedora Rawhide:
```
In file included from /builddir/build/BUILD/ParaView-v5.8.0-RC1/VTK/GUISupport/Qt/QVTKRenderWindowAdapter.cxx:20:
/builddir/build/BUILD/ParaView-v5.8.0-RC1/VTK/GUISupport/Qt/QVTKRenderWindowAdapter.cxx: In member function 'void QVTKRenderWindowAdapter::QVTKInternals::paint()':
/builddir/build/BUILD/ParaView-v5.8.0-RC1/VTK/Common/Core/vtkLogger.h:487:69: error: format not a string literal and no format arguments [-Werror=format-security]
487 | : vtkLogger::LogScopeRAII(level, __FILE__, __LINE__, __VA_ARGS__)
| ^
/builddir/build/BUILD/ParaView-v5.8.0-RC1/VTK/Common/Core/vtkLogger.h:490:3: note: in expansion of macro 'vtkVLogScopeF'
490 | vtkVLogScopeF(vtkLogger::VERBOSITY_##verbosity_name, __VA_ARGS__)
| ^~~~~~~~~~~~~
/builddir/build/BUILD/ParaView-v5.8.0-RC1/VTK/Common/Core/vtkLogger.h:492:45: note: in expansion of macro 'vtkLogScopeF'
492 | #define vtkLogScopeFunction(verbosity_name) vtkLogScopeF(verbosity_name, __func__)
| ^~~~~~~~~~~~
/builddir/build/BUILD/ParaView-v5.8.0-RC1/VTK/GUISupport/Qt/QVTKRenderWindowAdapter.cxx:273:5: note: in expansion of macro 'vtkLogScopeFunction'
273 | vtkLogScopeFunction(TRACE);
| ^~~~~~~~~~~~~~~~~~~
cc1plus: some warnings being treated as errors
```
-Werror=format-security is a standard Fedora compile flag these days.9.0Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/vtk/vtk/-/issues/17758VTK/Python 3.8.1 unable to import vtkRenderingQt2020-01-21T07:45:27-05:00Andrew MacleanVTK/Python 3.8.1 unable to import vtkRenderingQtPython 3.8.1 may have problems regarding VTK; however these may also be Python/Windows dll issues.
- For Python 3.7.6 everything is Ok.
- For Python 3.8.1
- If you exclude the Qt build everything is Ok for vtkpython or running python...Python 3.8.1 may have problems regarding VTK; however these may also be Python/Windows dll issues.
- For Python 3.7.6 everything is Ok.
- For Python 3.8.1
- If you exclude the Qt build everything is Ok for vtkpython or running python from the command line. However Pycharm fails to load vtkCommonCore.
- If you include the Qt build, vtkpython fails to load vtkRenderingQt and Pycharm fails to load vtkCommonCore.
I ran `dependencies` and I can't see any indication of missing dlls. Attached is the command line output the environment (VTK) is Python 3.7.6 and (VTK1) is Python 3.8.1 [cmd_output.zip](/uploads/cb37c1cfb884be67784d4b1648d8ba58/cmd_output.zip)
Everything is Ok for Python 3.7.6 and vtkpython fails in Python 3.8.1 when vtkRenderingQt is included. Also in Python 3.8.1 Pycharm fails with the same error irrespective of whether vtkRenderingQt is included or not. The only thing I can see is that vtkRenderingQt loads the external Qt dlls. Maybe Pycharm sees the VTK dlls as one step removed?
I believe my paths are correct as evidenced that Python 3.7.6 works Ok.
**Note**: In Pycharm when `vtkCommonCore` fails to import the logic in `vtkmodules/__init__.py` tries to do a static load, hence the reference to `_vtkmodules_static`in the attached file.9.0https://gitlab.kitware.com/vtk/vtk/-/issues/17754Python 3.8.x has improved DLL search support available2020-01-27T03:22:30-05:00Ben BoeckelPython 3.8.x has improved DLL search support availableSo 3.8.x is now stricter in its DLL loading. DLLs beside the *executable* are no longer searched for by default. This causes various errors in the new ParaView Windows dashboard where I grabbed 3.8.1 since we should test that somewhere. ...So 3.8.x is now stricter in its DLL loading. DLLs beside the *executable* are no longer searched for by default. This causes various errors in the new ParaView Windows dashboard where I grabbed 3.8.1 since we should test that somewhere. This fails to load the `vtkParallelMPI4Py` module because it can't find `vtkParallelMPI4Py-pv5.7.dll` which is right beside `pvpython.exe`. We'll need to do something about this in `vtkPythonInterpreter` to add the executable directory to the `PATH` on interpreter start or otherwise. This new function looks promising: [`os._add_dll_directory`](https://github.com/python/cpython/commit/2438cdf0e932a341c7613bf4323d06b91ae9f1f1#diff-a6f29e907cbb5fffd44d453bcd7b77d5R13179):
```
os._add_dll_directory
path: path_t
Add a path to the DLL search path.
This search path is used when resolving dependencies for imported
extension modules (the module itself is resolved through sys.path),
and also by ctypes.
Returns an opaque value that may be passed to os.remove_dll_directory
to remove this directory from the search path.
```
The commit which changed things in upstream (added in 3.8.0a4): https://github.com/python/cpython/commit/2438cdf0e932a341c7613bf4323d06b91ae9f1f1#diff-fa4616621faa1cbc0e83ef8930bb3202
Cc: @utkarsh.ayachit @dgobbi @robertmaynard
Also: @jcfr @thewtex I don't know if you have an ITK-specific interpreter, but this likely affects you if so.
(Side note: this finally happened https://github.com/python/cpython/commit/24fe46081be3d1c01b3d21cb39bc3492ab4485a3)9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17744Failed to build Java Wrapper2019-12-07T14:09:04-05:00Tuan NguyenFailed to build Java WrapperI ran this command to generate the build for Java Wrapper:
`cmake -DVTK_WRAP_JAVA:BOOL=ON -DCMAKE_BUILD_TYPE:STRING=Release -DVTK_JAVA_SOURCE_VERSION:STRING=1.8 -DVTK_JAVA_TARGET_VERSION:STRING=1.8 ../VTK`
Then, I ran this command
...I ran this command to generate the build for Java Wrapper:
`cmake -DVTK_WRAP_JAVA:BOOL=ON -DCMAKE_BUILD_TYPE:STRING=Release -DVTK_JAVA_SOURCE_VERSION:STRING=1.8 -DVTK_JAVA_TARGET_VERSION:STRING=1.8 ../VTK`
Then, I ran this command
`make`
And I got the error:
```
/VTK-bin/Wrapping/Java/CMakeFiles/vtkImplicitProjectOnPlaneDistanceJava.cxx: In function ‘jint Java_vtk_vtkImplicitProjectOnPlaneDistance_GetNorm_18(JNIEnv*, jobject)’:
/VTK-bin/Wrapping/Java/CMakeFiles/vtkImplicitProjectOnPlaneDistanceJava.cxx:144:10: error: cannot convert ‘vtkImplicitProjectOnPlaneDistance::NormType’ to ‘jint {aka int}’ in return
return temp20;
^~~~~~
Wrapping/Java/CMakeFiles/vtkFiltersCoreJava.dir/build.make:2007: recipe for target 'Wrapping/Java/CMakeFiles/vtkFiltersCoreJava.dir/CMakeFiles/vtkImplicitProjectOnPlaneDistanceJava.cxx.o' failed
make[2]: *** [Wrapping/Java/CMakeFiles/vtkFiltersCoreJava.dir/CMakeFiles/vtkImplicitProjectOnPlaneDistanceJava.cxx.o] Error 1
```
It seems like SWIG does not treat enum NormType as enum in Java, but instead treat it as an integer.
What do I need to do to fix this error?9.0David GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/17737VTK failed with error C2039: 'min': is not a member of 'std' under /permissiv...2019-11-27T20:03:10-05:00QuellaZhangVTK failed with error C2039: 'min': is not a member of 'std' under /permissive- mode on MSVCVTK failed due to "error C2039: 'min': is not a member of 'std'" under /permissive- mode on MSVC, we use VTK master branch latest srouce code. Could you please help take a look at this? Thanks in advance!
**Steps to reproduce the behavi...VTK failed due to "error C2039: 'min': is not a member of 'std'" under /permissive- mode on MSVC, we use VTK master branch latest srouce code. Could you please help take a look at this? Thanks in advance!
**Steps to reproduce the behavior:**
1. git clone https://gitlab.kitware.com/vtk/vtk.git D:\VTK\src
1. Open a VS 2017 x86 command prompt and browse to D:\VTK
1. mkdir build_x86 && pushd build_x86
1. set _CL_=/permissive-
1. cmake -G "Visual Studio 15 2017" -DCMAKE_SYSTEM_VERSION=10.0.17134.0 -DBUILD_SHARED_LIBS=OFF -DBUILD_TESTING=ON -DBUILD_EXAMPLES=OFF -VTK_IGNORE_CMAKE_CXX11_CHECKS=TRUE ..\src
1. msbuild /m /p:Configuration=Release;Platform=Win32 All_BUILD.vcxproj /t:Rebuild
**Error Message:**
D:\VTK\src\Common\Core\vtkBuffer.h(166): error C2039: 'min': is not a member of 'std'
D:\VTK\src\Common\Core\vtkBuffer.h(166): error C2039: 'min': is not a member of 'std'
D:\VTK\src\Common\Core\vtkBuffer.h(166): error C2039: 'min': is not a member of 'std'
D:\VTK\src\Common\Core\vtkBuffer.h(166): error C2039: 'min': is not a member of 'std'
D:\VTK\src\Common\Core\vtkBuffer.h(166): error C2039: 'min': is not a member of 'std'9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17733Paraview 5.7 fails to build with openmpi on Fedora Rawhide2022-05-19T18:16:09-04:00Orion PoplawskiParaview 5.7 fails to build with openmpi on Fedora RawhideTrying to update the Fedora paraview package to 5.7. Getting the following:
```
[ 97%] Linking CXX executable ../bin/pvserver
cd /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/CommandLineExecutables && /usr/bin/cma...Trying to update the Fedora paraview package to 5.7. Getting the following:
```
[ 97%] Linking CXX executable ../bin/pvserver
cd /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/CommandLineExecutables && /usr/bin/cmake -E cmake_link_script CMakeFiles/pvserver.dir/link.txt --verbose=1
/usr/bin/c++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=zEC12 -mtune=z13 -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g -DNDEBUG -Wl,-lc -Wl,-lc -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld CMakeFiles/pvserver.dir/pvserver.cxx.o -o ../bin/pvserver -Wl,-rpath,"\$ORIGIN/../lib64:/usr/lib64/openmpi/lib:" ../lib64/libvtkPVServerManagerApplication-pv5.7.so.5.7 ../lib64/libvtkUtilitiesPythonInitializer-pv5.7.so.5.7 ../lib64/libvtkPVServerManagerCore-pv5.7.so.5.7 ../lib64/libvtkPVServerImplementationCore-pv5.7.so.5.7 ../lib64/libvtkPVClientServerCoreCore-pv5.7.so.5.7 ../lib64/libvtkPVVTKExtensionsCore-pv5.7.so.5.7 ../lib64/libvtkPVCore-pv5.7.so.5.7 ../lib64/libvtkClientServer-pv5.7.so.5.7 ../lib64/libvtkPythonInterpreter-pv5.7.so.5.7 ../lib64/libvtkIOXMLParser-pv5.7.so.5.7 ../lib64/libvtkIOImage-pv5.7.so.5.7 ../lib64/libvtkPVVTKExtensionsSIL-pv5.7.so.5.7 ../lib64/libvtkFiltersParallel-pv5.7.so.5.7 ../lib64/libvtkFiltersExtraction-pv5.7.so.5.7 ../lib64/libvtkFiltersModeling-pv5.7.so.5.7 ../lib64/libvtkFiltersSources-pv5.7.so.5.7 ../lib64/libvtkFiltersGeneral-pv5.7.so.5.7 ../lib64/libvtkFiltersGeometry-pv5.7.so.5.7 ../lib64/libvtkFiltersCore-pv5.7.so.5.7 ../lib64/libvtkParallelCore-pv5.7.so.5.7 ../lib64/libvtkIOLegacy-pv5.7.so.5.7 ../lib64/libvtkIOCore-pv5.7.so.5.7 /usr/lib64/libprotobuf.so /usr/lib64/libjsoncpp.so ../lib64/libvtkCommonExecutionModel-pv5.7.so.5.7 ../lib64/libvtkCommonDataModel-pv5.7.so.5.7 ../lib64/libvtkCommonSystem-pv5.7.so.5.7 ../lib64/libvtkCommonMisc-pv5.7.so.5.7 ../lib64/libvtkCommonTransforms-pv5.7.so.5.7 ../lib64/libvtkCommonMath-pv5.7.so.5.7 ../lib64/libvtkCommonCore-pv5.7.so.5.7 -lpthread /usr/lib64/libpython3.8.so ../lib64/libvtksys-pv5.7.so.5.7 -ldl -Wl,-rpath-link,/builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64:/usr/lib64/openmpi/lib
make[2]: Leaving directory '/builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `ompi_mpi_cxx_op_intercept'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Win::Free()'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Datatype::Free()'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Comm::Comm()'
collect2: error: ld returned 1 exit status
make[2]: *** [CommandLineExecutables/CMakeFiles/pvserver.dir/build.make:120: bin/pvserver] Error 1
```
Full log: https://kojipkgs.fedoraproject.org//work/tasks/1379/39091379/build.log. See this on all arches.9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17731Upgrade mpi4py for python 3.82019-12-11T06:56:21-05:00Nicolas VuailleUpgrade mpi4py for python 3.8mpi4py as used in VTK cannot be build with python3.8.
Referring to the upstream repo (https://bitbucket.org/mpi4py/mpi4py/commits/all), the version 3.0.3 should be OK.
Is it possible to upgrade mpi4py ?
* python 3.8.0
* openmpi 4.0.2...mpi4py as used in VTK cannot be build with python3.8.
Referring to the upstream repo (https://bitbucket.org/mpi4py/mpi4py/commits/all), the version 3.0.3 should be OK.
Is it possible to upgrade mpi4py ?
* python 3.8.0
* openmpi 4.0.2
* gcc 9.2.0
* vtk 968566a0697e425ca461f5b93af2ba90964340e2
* cython 0.29.149.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17728Third parties still include <hdf5.h> instead of its mangled equivalent2019-12-11T06:57:19-05:00T.J. CoronaThird parties still include <hdf5.h> instead of its mangled equivalentThis causes issues with using ThirdParty hdf5.
@ben.boeckelThis causes issues with using ThirdParty hdf5.
@ben.boeckel9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17725Build error in VTK-based project: “include called with wrong number of argume...2019-11-12T20:12:55-05:00Andras LassoBuild error in VTK-based project: “include called with wrong number of arguments. include() only takes one file.”Build fails when a VTK-based library is configured with VTK-8.90. It worked well with VTK-8.2.
The error message is:
include called with wrong number of arguments. include() only takes one file.
After some digging and internet search ...Build fails when a VTK-based library is configured with VTK-8.90. It worked well with VTK-8.2.
The error message is:
include called with wrong number of arguments. include() only takes one file.
After some digging and internet search it turned out that it caused trouble at a number of other projects, too (VTK examples, PCL, etc).
The solution is to delete include(${VTK_USE_FILE}), which was necessary for building with older VTK versions.
To make transition of projects to VTK-8.9 easier and avoid unnecessary developer frustration, please create a dummy VTK_USE_FILE that prints a meaningful warning message (or prints an error message and aborts the build). This mechanism only needs to kept until most projects make their transition (can be removed in a couple of years).9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17707Ffmpeg support - libavresample is deprecated2020-04-01T08:29:36-04:00Henrique GropelliFfmpeg support - libavresample is deprecatedHello! Ffmpeg when compiled from latest version from git, doesn't build anymore libavresample which were switched to libswresample. While cmake is searching for libavresample.Hello! Ffmpeg when compiled from latest version from git, doesn't build anymore libavresample which were switched to libswresample. While cmake is searching for libavresample.9.0Ken MartinKen Martinhttps://gitlab.kitware.com/vtk/vtk/-/issues/17706vtkOpenGLShaderProperty::DeepCopy does not copy UserShaderReplacements2019-11-06T11:05:33-05:00Andreas BuykxvtkOpenGLShaderProperty::DeepCopy does not copy UserShaderReplacementsI would expect a DeepCopy method to copy the UserShaderReplacements method but it doesn't. It only performs the vtkShaderProperty::DeepCopy(p)I would expect a DeepCopy method to copy the UserShaderReplacements method but it doesn't. It only performs the vtkShaderProperty::DeepCopy(p)9.0https://gitlab.kitware.com/vtk/vtk/-/issues/17704deprecate INVERTIBLE_LUT ValuePass mode2019-10-17T12:52:06-04:00David E. DeMarledeprecate INVERTIBLE_LUT ValuePass modeThe SGI patent on floating point textures expired in 2016. Mesa has had unconditional support since then and other implementations typically had it before then. We can now drop the original deferred rendering hack where we scaled and bia...The SGI patent on floating point textures expired in 2016. Mesa has had unconditional support since then and other implementations typically had it before then. We can now drop the original deferred rendering hack where we scaled and biased values into 24 bits and instead draw and retrieve values directly.9.0David E. DeMarleDavid E. DeMarlehttps://gitlab.kitware.com/vtk/vtk/-/issues/17700diy2 does not compile using intel compiler2019-12-09T13:26:55-05:00Andreas Buykxdiy2 does not compile using intel compilerI'm trying to build VTK (commit 6295ff2235) on linux using our intel compiler and get compiler errors when building diy2.
The errors are related to the expansion of FMT_DEPRECATED, like
```
<path-to-VTK>/ThirdParty/diy2/vtkdiy2/incl...I'm trying to build VTK (commit 6295ff2235) on linux using our intel compiler and get compiler errors when building diy2.
The errors are related to the expansion of FMT_DEPRECATED, like
```
<path-to-VTK>/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/fmt/core.h(478): error: identifier "parse_context" is undefined
using parse_context FMT_DEPRECATED = basic_parse_context<char>;
```
The FMT_DEPRECATED macro is defined as
```
#ifndef FMT_DEPRECATED
# if (FMT_HAS_CPP_ATTRIBUTE(deprecated) && __cplusplus >= 201402L) || \
FMT_MSC_VER >= 1900
# define FMT_DEPRECATED [[deprecated]]
# else
# if defined(__GNUC__) || defined(__clang__)
# define FMT_DEPRECATED __attribute__((deprecated))
# elif FMT_MSC_VER
# define FMT_DEPRECATED __declspec(deprecated)
# else
# define FMT_DEPRECATED /* deprecated */
# endif
# endif
#endif
```
Our compiler version is 19.0.2.187 20190117 which has __cplusplus >= 201402L and supports the [[deprecated]] attribute, but it does not have __has_cpp_attribute (which is a C++20 feature). The FMT_DEPRECATED macro however expands to __attribute__((deprecated)) which causes compiler errors.
I fixed my build by using
```
#ifndef FMT_DEPRECATED
# if (FMT_HAS_CPP_ATTRIBUTE(deprecated) && __cplusplus >= 201402L) || \
FMT_MSC_VER >= 1900 || \
defined(__ICC)
# define FMT_DEPRECATED [[deprecated]]
# else
# if defined(__GNUC__) || defined(__clang__)
# define FMT_DEPRECATED __attribute__((deprecated))
# elif FMT_MSC_VER
# define FMT_DEPRECATED __declspec(deprecated)
# else
# define FMT_DEPRECATED /* deprecated */
# endif
# endif
#endif
```
but this may not work properly I suppose for older intel compilers.
@caitlin.ross Could you please have a look at this? Thanks!9.0