VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2024-03-07T08:22:30-05:00https://gitlab.kitware.com/vtk/vtk/-/issues/19265OpenTURNS not correctly looked up/forwarded in generated cmake configs2024-03-07T08:22:30-05:00Alexander NeumannOpenTURNS not correctly looked up/forwarded in generated cmake configsProblem was that I add a linker error due to not being able to open `OT.lib`. As it turns out the OpenTURNS filter as `$<LINK_ONLY:OT>` where `OT` is a target if a `find_package` call for OpenTURNS would have been done. The module info d...Problem was that I add a linker error due to not being able to open `OT.lib`. As it turns out the OpenTURNS filter as `$<LINK_ONLY:OT>` where `OT` is a target if a `find_package` call for OpenTURNS would have been done. The module info does not contain the information for VTK to actually generate that `find_package` call to OpenTURNS.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19264vtkExodusII name mangling not complete2024-03-07T12:00:55-05:00Alexander NeumannvtkExodusII name mangling not completeHad to devendor exodusII because of a symbol conflict. Name mangling seems to be incomplete for the vendored exodusII. Conflicting symbol is `exerrval`
Here is the patch to devendor:
[devendor_exodusII.patch](/uploads/ba534a9eb6506c4f3e...Had to devendor exodusII because of a symbol conflict. Name mangling seems to be incomplete for the vendored exodusII. Conflicting symbol is `exerrval`
Here is the patch to devendor:
[devendor_exodusII.patch](/uploads/ba534a9eb6506c4f3e10069ffa26acbf/devendor_exodusII.patch)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19207Enable testing ABI Mangling with VTK_ENABLE_KITS2023-12-28T13:08:17-05:00Ryan Krattigerryan.krattiger@kitware.comEnable testing ABI Mangling with VTK_ENABLE_KITSThe ABI Mangling test parse the contents of the compiled binaries for symbols with with non-`"hidden"` visibility and verifies all of these symbols contain the ABI Namespace string.
There are a set of cases where each VTK module will li...The ABI Mangling test parse the contents of the compiled binaries for symbols with with non-`"hidden"` visibility and verifies all of these symbols contain the ABI Namespace string.
There are a set of cases where each VTK module will list EXCEPTIONS to the ABI Namespace. In the case of VTK Kits, multiple modules will be linked into a common binary. When the ABI mangling test is run for each module in the Kit it will not know about exceptions for its module, but the kit binary may also contain exceptionable symbols from other modules in that kit.
The original solution for this was to inspect the `TARGET_OBJECTS` for each module. However, on some platforms the symbol attribute `visibility="hidden"` is not applied until the final library is linked. This leads to false positive results where private symbols that do not require ABI mangling are listed as errors in the test.
A possible solution to this could be to aggregate a list of module `TARGET_FILES`, strip duplicates, and create an ABI mangling test for each of the aggregated files with their appropriate exceptions.
CC: @ben.boeckel @svenevsRyan Krattigerryan.krattiger@kitware.comRyan Krattigerryan.krattiger@kitware.comhttps://gitlab.kitware.com/vtk/vtk/-/issues/19200FindFreetype: port implib FindFreeType.cmake changes from upstream CMake2023-12-19T09:39:10-05:00John ParentFindFreetype: port implib FindFreeType.cmake changes from upstream CMakehttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/8775 Backported https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9973 into CMake. However, https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9973 introduces a bug when consider...https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8775 Backported https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9973 into CMake. However, https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9973 introduces a bug when considering import libraries on Windows. https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8920 makes the required patch on the CMake side. We need to port the changes in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8920 to VTK to deal with Freetype's import libraries with CMakes older than 3.28.1.
cc @ben.boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19194TBB versions prior to TBB 2019 Update 9 does not guard target creation2023-12-19T07:41:53-05:00Dan LipsaTBB versions prior to TBB 2019 Update 9 does not guard target creationWe need to update VTK to use that version of TBB
See
https://gitlab.kitware.com/paraview/paraview/-/merge_requests/6375#note_1449745We need to update VTK to use that version of TBB
See
https://gitlab.kitware.com/paraview/paraview/-/merge_requests/6375#note_14497459.3https://gitlab.kitware.com/vtk/vtk/-/issues/19129Name mangling issue when combining VTK + QT for webasm build (Emscripten) for...2023-10-17T19:35:05-04:00ruell magpayoName mangling issue when combining VTK + QT for webasm build (Emscripten) for FreetypeFollow this steps in the original post including the versions:
https://discourse.vtk.org/t/vtk-qt-in-emscripten-webassembly-opengl-error-unknown-type-name-pfnglpushdebuggroupproc-did-you-mean-pfnglpushdebuggroupkhrproc/12447/8
issue is ...Follow this steps in the original post including the versions:
https://discourse.vtk.org/t/vtk-qt-in-emscripten-webassembly-opengl-error-unknown-type-name-pfnglpushdebuggroupproc-did-you-mean-pfnglpushdebuggroupkhrproc/12447/8
issue is freetype conflict in definitions between QT 6.5.0 and any version of VTK including 9.3.0
```
wasm-ld: error: duplicate symbol: ft_mem_realloc
>>> defined in ../../dependencies/VTK-9.2.6/lib\\libvtkfreetype-9.2.a(ftbase.c.o)
>>> defined in C:/Qt/6.5.0/wasm_singlethread/lib/libQt6BundledFreetype.a(ftbase.c.o)
wasm-ld: error: duplicate symbol: FT_GlyphLoader_CheckPoints
>>> defined in ../../dependencies/VTK-9.2.6/lib\\libvtkfreetype-9.2.a(ftbase.c.o)
>>> defined in C:/Qt/6.5.0/wasm_singlethread/lib/libQt6BundledFreetype.a(ftbase.c.o)
wasm-ld: error: duplicate symbol: FT_GlyphLoader_CheckSubGlyphs
>>> defined in ../../dependencies/VTK-9.2.6/lib\\libvtkfreetype-9.2.a(ftbase.c.o)
>>> defined in C:/Qt/6.5.0/wasm_singlethread/lib/libQt6BundledFreetype.a(ftbase.c.o)
```https://gitlab.kitware.com/vtk/vtk/-/issues/19128Qt + osmesa = broken, but no CMake error?2023-10-11T14:45:01-04:00Matthew WoehlkeQt + osmesa = broken, but no CMake error?I configured VTK with (among other things):
```
-DVTK_BUILD_ALL_MODULES=ON
-DVTK_OPENGL_HAS_OSMESA:BOOL=ON
-DVTK_USE_X:BOOL=OFF
```
I am told that this is broken (note that `-DVTK_BUILD_ALL_MODULES=ON` enables Qt), and that CMake should...I configured VTK with (among other things):
```
-DVTK_BUILD_ALL_MODULES=ON
-DVTK_OPENGL_HAS_OSMESA:BOOL=ON
-DVTK_USE_X:BOOL=OFF
```
I am told that this is broken (note that `-DVTK_BUILD_ALL_MODULES=ON` enables Qt), and that CMake should have complained about it.https://gitlab.kitware.com/vtk/vtk/-/issues/19049Use `FORTIFY_SOURCE=3` somewhere on CI2023-08-15T08:11:31-04:00Sean McBrideUse `FORTIFY_SOURCE=3` somewhere on CISince glibc 2.34 and GCC 12, there is a new FORTIFY_SOURCE level (3) that would be nice to have on CI.
You can read more about it here for example:
https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#
@ben.b...Since glibc 2.34 and GCC 12, there is a new FORTIFY_SOURCE level (3) that would be nice to have on CI.
You can read more about it here for example:
https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#
@ben.boeckel is there a bot with new enough glibc / gcc that this could be added to?
(See also #18100.)https://gitlab.kitware.com/vtk/vtk/-/issues/19047Bad module dependency for vtkGenerateTimeSteps2023-08-22T09:22:33-04:00Charly BollingerBad module dependency for vtkGenerateTimeSteps## Description
The useful `vtkGenerateTimeSteps` filter can be found in the `VTK::FiltersHybrid` module. Several sources could need this filter to avoid code duplication, if they wanted the source to allow time steps generation. This is...## Description
The useful `vtkGenerateTimeSteps` filter can be found in the `VTK::FiltersHybrid` module. Several sources could need this filter to avoid code duplication, if they wanted the source to allow time steps generation. This is the case of the `vtkTimeSourceExample` and the more recent `vtkSpatioTemporalHarmonicsSource`.
However, the `VTK::FiltersHybrid` module implies adding strong dependencies, such as the `VTK::RenderingCore` module. This would be bad to need the rendering module to be able to create sources.
## Possible fixes
From the best to the worst solution imo:
* The `vtkGenerateTimeSteps` filter should be moved out of this module, in a better fitting module such as `VTK::FiltersCore` or `VTK::FiltersGeneral`.
* The `VTK::FiltersHybrid` module should move every filter depending on rendering in a more appropriate module, to remove the `VTK::RenderingCore` module dependency.
* Sources needing the `vtkGenerateTimeSteps` filter should be moved in the `VTK::FiltersHybrid` module.https://gitlab.kitware.com/vtk/vtk/-/issues/19046ThirdParty: audit `vtk_module_find_package` calls for `PRIVATE_IF_SHARED` eli...2023-08-08T09:26:05-04:00Ben BoeckelThirdParty: audit `vtk_module_find_package` calls for `PRIVATE_IF_SHARED` eligibilitySee !10393.See !10393.https://gitlab.kitware.com/vtk/vtk/-/issues/19001SDPX: Parse generated files for SPDX generation2023-08-01T05:36:01-04:00Mathieu Westphal (Kitware)SDPX: Parse generated files for SPDX generationCurrently, SPDX generation (see here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10200) happens at build time before the module target.
However, it does no depend on all the sources files, which means some generated source files...Currently, SPDX generation (see here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10200) happens at build time before the module target.
However, it does no depend on all the sources files, which means some generated source files may be missing at generation time.
For now, these files are just dropped but technically it would be possible to add all files as dependencies, the same way the `hierarchy` target works.https://gitlab.kitware.com/vtk/vtk/-/issues/18819Raytracing module does not link with GCC 4.8.52023-03-01T10:51:51-05:00Mathieu Westphal (Kitware)Raytracing module does not link with GCC 4.8.5RenderingRaytracing module does not link correctly with GCC 4.8.5, it fails with the following error (reproduced in ParaView):
```shell
[ 96%] Building CXX object Clients/CommandLineExecutables/CMakeFiles/pvbatch.dir/pvbatch.cxx.o
build...RenderingRaytracing module does not link correctly with GCC 4.8.5, it fails with the following error (reproduced in ParaView):
```shell
[ 96%] Building CXX object Clients/CommandLineExecutables/CMakeFiles/pvbatch.dir/pvbatch.cxx.o
build/lib/libvtkRenderingRayTracing-pv5.11.so.1: undefined reference to `__cpu_indicator_init'
build/lib/libvtkRenderingRayTracing-pv5.11.so.1: undefined reference to `__cpu_model'
collect2: error: ld returned 1 exit status
Clients/CommandLineExecutables/CMakeFiles/pvdataserver.dir/build.make:108: recipe for target 'bin/pvdataserver' failed
make[2]: *** [bin/pvdataserver] Error 1
CMakeFiles/Makefile2:43826: recipe for target 'Clients/CommandLineExecutables/CMakeFiles/pvdataserver.dir/all' failed
make[1]: *** [Clients/CommandLineExecutables/CMakeFiles/pvdataserver.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 96%] Building CXX object CMakeFiles/vtkRemotingViewsPython.dir/CMakeFiles/vtkRemotingViewsPython/vtkSMPVRepresentationProxyPython.cxx.o
build/lib/libvtkRenderingRayTracing-pv5.11.so.1: undefined reference to `__cpu_indicator_init'
build/lib/libvtkRenderingRayTracing-pv5.11.so.1: undefined reference to `__cpu_model'
collect2: error: ld returned 1 exit status
Clients/CommandLineExecutables/CMakeFiles/pvrenderserver.dir/build.make:108: recipe for target 'bin/pvrenderserver' failed
make[2]: *** [bin/pvrenderserver] Error 1
```
works fine in GCC7https://gitlab.kitware.com/vtk/vtk/-/issues/18750vtk wheel: vendored proj does not work because the database is not included2022-12-16T19:22:02-05:00Ben Boeckelvtk wheel: vendored proj does not work because the database is not includedSo VTK's wheels contain `libproj` but not in a way that works because its `proj.db` is not in the wheel itself. Alas, Python packaging intersecting VTK's build system is a nightmare and I was able to get it into the wheel by abusing Pyth...So VTK's wheels contain `libproj` but not in a way that works because its `proj.db` is not in the wheel itself. Alas, Python packaging intersecting VTK's build system is a nightmare and I was able to get it into the wheel by abusing Python's duck typing and just path-traversing in `package_data`, but not in a way that `pip install` liked on install (why does `bdist_wheel` not error on the creation side? who knows):
```
ERROR: For req: vtk==9.2.20221216.dev0. Unknown scheme key used in /home/boeckb/misc/builds/vtk/build-whl/dist/vtk-9.2.20221216.dev0-cp311-cp311-linux_x86_64.whl: share (for file 'vtk-9.2.20221216.data/share/vtk/proj/proj.db'). .data directory contents should be in subdirectories named with a valid scheme key (data, headers, platlib, purelib, scripts)
```
So the wheel build needs to update how the database is placed into the build tree in `ThirdParty/libproj/vtklibproj/data/CMakeLists.txt` and get it into the wheel with whatever `setuptools` wants in `CMake/setup.py.in`.
Cc: @jcfr @banesullivan @dgobbi @danlipsahttps://gitlab.kitware.com/vtk/vtk/-/issues/18746Configure fails if VTK_BUILD_TESTING=ON and VTK_GROUP_ENABLE_Rendering=OFF2023-01-09T21:45:23-05:00Sean McBrideConfigure fails if VTK_BUILD_TESTING=ON and VTK_GROUP_ENABLE_Rendering=OFFWith current master, if I create a fresh bin directory and do a fresh cmake configure, then just make 2 changes:
```
VTK_BUILD_TESTING *WANT ...With current master, if I create a fresh bin directory and do a fresh cmake configure, then just make 2 changes:
```
VTK_BUILD_TESTING *WANT
VTK_GROUP_ENABLE_Rendering *DONT_WANT
```
Then try to re-configure, it fails with:
```
CMake Error at CMake/vtkModule.cmake:2618 (message):
The VTK::octree dependency is missing for VTK::RenderingLabel. The
`vtk_module_scan` for this module used `ENABLE_TESTS WANT`. This is a
known issue, but the fix is not trivial. You may either change the flag
used to control testing for this scan or explicitly enable the VTK::octree
module.
Call Stack (most recent call first):
CMakeLists.txt:450 (vtk_module_build)
```
If I try instead the stronger:
```
VTK_BUILD_TESTING *ON
VTK_GROUP_ENABLE_Rendering *OFF
```
It fails differently:
```
CMake Error at CMake/vtkModule.cmake:1038 (message):
The VTK::IOMovie module (enabled via a `WANT` setting (via
`VTK_GROUP_ENABLE_StandAlone`)) requires the disabled module
VTK::TestingRendering (disabled via a `NO` setting (via
`VTK_GROUP_ENABLE_Rendering`)).
Call Stack (most recent call first):
CMakeLists.txt:365 (vtk_module_scan)
```
Shouldn't one be able to build VTK without rendering? But still have testing of what remains?
@ben.boeckel I'm trying this because the old Rogue7 bot pretty consistently kernel panics running VTK tests. I'm hoping to eliminate the OpenGL drivers to avoid that, and at least still build & test something.https://gitlab.kitware.com/vtk/vtk/-/issues/18714Vtk9 fails to build when some other (unknown) package is installed: QQMLCompo...2023-05-11T10:20:07-04:00yurivictVtk9 fails to build when some other (unknown) package is installed: QQMLComponent: Component is not readyError:
```
FAILED: /lib/qml/VTK.9.2/libqmlvtkplugin.so lib/qml/VTK.9.2/plugins.qmltypes /usr/ports/math/vtk9/work/.build/lib/qml/VTK.9.2/plugins.qmltypes
QQMLComponent: Component is not ready
```
This error occurs on FreeBSD only when s...Error:
```
FAILED: /lib/qml/VTK.9.2/libqmlvtkplugin.so lib/qml/VTK.9.2/plugins.qmltypes /usr/ports/math/vtk9/work/.build/lib/qml/VTK.9.2/plugins.qmltypes
QQMLComponent: Component is not ready
```
This error occurs on FreeBSD only when some unrelated, unknown package is installed.
Please see the [downstream bug report](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267718).https://gitlab.kitware.com/vtk/vtk/-/issues/18671Improve Java packaging and CI2022-09-29T04:43:59-04:00Ben BoeckelImprove Java packaging and CIThere is a Maven packaging effort of VTK. Find out what could make things better from VTK's side.
/cc @sebastien.jourdainThere is a Maven packaging effort of VTK. Find out what could make things better from VTK's side.
/cc @sebastien.jourdainhttps://gitlab.kitware.com/vtk/vtk/-/issues/18624Update diy2 ti fix build errors.2023-08-17T16:15:22-04:00Alexander NeumannUpdate diy2 ti fix build errors.diy dropped small vector form choco to itlib.
Reason:
choco small vector won't compile with C++20 (and I currently see those errors.)diy dropped small vector form choco to itlib.
Reason:
choco small vector won't compile with C++20 (and I currently see those errors.)9.3Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18605CI: Unit tests being skipped in mac2022-08-02T17:35:16-04:00Vicente Boleavicente.bolea@kitware.comCI: Unit tests being skipped in macOSX VTK CI instances are skipping a set of unit-tests since it cannot find numpy.
Examples are here:
- https://open.cdash.org/test/749318603
- https://open.cdash.org/viewTest.php?onlydelta&buildid=8027779
We either need to install num...OSX VTK CI instances are skipping a set of unit-tests since it cannot find numpy.
Examples are here:
- https://open.cdash.org/test/749318603
- https://open.cdash.org/viewTest.php?onlydelta&buildid=8027779
We either need to install numpy in those machines or properly disable these tests for OSX buildshttps://gitlab.kitware.com/vtk/vtk/-/issues/18596Follow-up from "vtkCompilerWarningFlags: populate warning flags"2022-07-05T18:10:51-04:00Ben BoeckelFollow-up from "vtkCompilerWarningFlags: populate warning flags"`-Wno-vla-extension` and `-Wno-vla`
The following discussion from !9321 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9321#note_1207948):
> Where are we using V...`-Wno-vla-extension` and `-Wno-vla`
The following discussion from !9321 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9321#note_1207948):
> Where are we using VLAs? We really shouldn't.
Cc: @seanmhttps://gitlab.kitware.com/vtk/vtk/-/issues/18595Follow-up from "vtkCompilerWarningFlags: populate warning flags"2022-08-08T11:05:54-04:00Ben BoeckelFollow-up from "vtkCompilerWarningFlags: populate warning flags"`-Wno-zero-as-null-pointer-constant`
The following discussion from !9321 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9321#note_1207947):
> `clang-tidy` should...`-Wno-zero-as-null-pointer-constant`
The following discussion from !9321 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9321#note_1207947):
> `clang-tidy` should be enforcing this; why is this disabled?
Cc: @seanm