VTK 9.4.1

[cwant]

No description provided.

[ccoulombe]

The same applies to the gompi version

[ccoulombe]

We should not depend on Scipy-stack directly.

Better to have flexibility and have it in the modluafooter if required. But I think in this case we can remove the scipy-stack and simply use the numpy module as builddep

[cwant]

@ccoulombe Interesting, I didn't know that there was a numpy module.

I did build it by first moving pretty every dependency to the builddeps as suggested, but it fails on the import vtk sanity check for Python 3.13 (the first version it tries):

== 2025-03-27 15:06:14,134 build_log.py:171 ERROR EasyBuild crashed with an error (at easybuild/tools/build_log.py:111 in caller_info): Sanity check failed: sanity check command python -c 'import vtk' exited with code 1 (output: Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import vtk
  File "/home/cwant/.local/easybuild/software/2023/x86-64-v3/Compiler/gcc12/vtk/9.4.1/lib/python3.13/site-packages/vtk.py", line 26, in <module>
    from vtkmodules.vtkPythonContext2D import *
ImportError: /home/cwant/.local/easybuild/software/2023/x86-64-v3/Compiler/gcc12/vtk/9.4.1/lib/libvtkWrappingPythonCore3.11-9.4.so.1: undefined symbol: _Py_HashPointer
) (at easybuild/framework/easyblock.py:3674 in _sanity_check_step)

Is it interesting that it's an issue with 3.11 stuff?

[ccoulombe]

Ishh, that's not good. So I guess we were wrong, and that dirty bug is not resolved after all :( :(

Updated

[ccoulombe]

VTK 9.4.1 still has issues with mixed python symbols

[ostueker]

VTK 9.4.2 has been released:
https://vtk.org/download/

[ostueker]

I've tried this with VTK 9.4.2 instead and I still see the same issue that @cwant reported in March:

== 2025-07-08 16:48:44,574 build_log.py:226 ERROR EasyBuild encountered an error (at easybuild/tools/build_log.py:166 in caller_info): Sanity check failed: sanity check command module load scipy-stack && python -c 'import vtk' failed with exit code 1 (output: Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import vtk
  File "/home/stuekero/.local/easybuild/software/2023/x86-64-v3/Compiler/gcc13/vtk/9.4.2/lib/python3.13/site-packages/vtk.py", line 26, in <module>
    from vtkmodules.vtkPythonContext2D import *
ImportError: /home/stuekero/.local/easybuild/software/2023/x86-64-v3/Compiler/gcc13/vtk/9.4.2/lib/libvtkWrappingPythonCore3.11-9.4.so.1: undefined symbol: _Py_HashPointer
) (at easybuild/framework/easyblock.py:4362 in _sanity_check_step)

After investigating a bit, I think I have an idea what's happening:

1. The sanity check uses the first Python-version (in this case 3.13) to run import vtk
2. That in turn runs from vtkmodules.vtkPythonContext2D import *
3. vtkPythonContext2D then tries to load libvtkWrappingPythonCore3.11-9.4.so.1 which fails because that is intended for Python 3.11 but we are using Python 3.13

How that?
Well if we check what vtkmodules/vtkPythonContext2D.*.so is linked against we see that it is loading $EBROOTVTK/lib/libvtkPythonContext2D-9.4.so.1 :

$ ldd $EBROOTVTK/lib/python3.13/site-packages/vtkmodules/vtkPythonContext2D.cpython-313-x86_64-linux-gnu.so | head -n5
        linux-vdso.so.1 (0x00007ffe5a9e5000)
        libc.so.6 => /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6 (0x00007fae9f053000)
        libvtkPythonContext2D-9.4.so.1 => $EBROOTVTK/lib/libvtkPythonContext2D-9.4.so.1 (0x00007fae9f047000)
        libvtkWrappingPythonCore3.13-9.4.so.1 => $EBROOTVTK/lib/libvtkWrappingPythonCore3.13-9.4.so.1 (0x00007fae9effb000)
        libvtkRenderingContext2D-9.4.so.1 => $EBROOTVTK/lib/libvtkRenderingContext2D-9.4.so.1 (0x00007fae9efac000)
[...]

(I replaced some long paths with $EBROOTVTK to make it more readable)

Now if we look at what libvtkPythonContext2D-9.4.so.1 is linked against, we see:

$ ldd $EBROOTVTK/lib/libvtkPythonContext2D-9.4.so.1 | head -n5
        linux-vdso.so.1 (0x00007ffd9cdce000)
        libc.so.6 => /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6 (0x00007effd985f000)
        libvtkRenderingContext2D-9.4.so.1 => $EBROOTVTK/lib/libvtkRenderingContext2D-9.4.so.1 (0x00007effd9810000)
        libvtkWrappingPythonCore3.11-9.4.so.1 => $EBROOTVTK/lib/libvtkWrappingPythonCore3.11-9.4.so.1 (0x00007effd97c4000)
        libvtkRenderingCore-9.4.so.1 => $EBROOTVTK/lib/libvtkRenderingCore-9.4.so.1 (0x00007effd9509000)
[...]

So we see that $EBROOTVTK/lib/libvtkPythonContext2D-9.4.so.1 is linked against libvtkWrappingPythonCore3.11-9.4.so.1 since it was last compiled against Python 3.11 and that overwrote the file libvtkPythonContext2D-9.4.so.1 that was linked against libvtkWrappingPythonCore3.12-9.4.so.1.

Therefore, even though $EBROOTVTK/lib/ should only contain libraries that are independent of a particular Python version, it is hard-coded against the last Python used by our multi_deps = {'Python': ['3.13', '3.12', '3.11']}

I really don't see any way how we can provide a single VTK module that works with more than one version of Python, or am I missing something?

[ostueker]

Falling back to a single Python version resolves the issue:

multi_deps = { 'Python': ['3.13' ]}

[ccoulombe]

This is a known issue with our VTK and ITK. The libraries gets mixed up on the so to link since we are using multiple pythons. Probably that we should only prodivide the vtk bindings from the wheelhouse and only the lib part from the module.

…

On Wed, Jul 9, 2025, 09:57 Oliver Stueker ***@***.***> wrote: *ostueker* left a comment (ComputeCanada/easybuild-easyconfigs#93) <#93 (comment)> I've tried this with VTK 9.4.2 instead and I still see the same issue that @cwant <https://github.com/cwant> reported in March: == 2025-07-08 16:48:44,574 build_log.py:226 ERROR EasyBuild encountered an error (at easybuild/tools/build_log.py:166 in caller_info): Sanity check failed: sanity check command module load scipy-stack && python -c 'import vtk' failed with exit code 1 (output: Traceback (most recent call last): File "<string>", line 1, in <module> import vtk File "/home/stuekero/.local/easybuild/software/2023/x86-64-v3/Compiler/gcc13/vtk/9.4.2/lib/python3.13/site-packages/vtk.py", line 26, in <module> from vtkmodules.vtkPythonContext2D import * ImportError: /home/stuekero/.local/easybuild/software/2023/x86-64-v3/Compiler/gcc13/vtk/9.4.2/lib/libvtkWrappingPythonCore3.11-9.4.so.1: undefined symbol: _Py_HashPointer ) (at easybuild/framework/easyblock.py:4362 in _sanity_check_step) After investigating a bit, I think I have an idea what's happening: 1. The sanity check uses the first Python-version (in this case 3.13) to run import vtk 2. That in turn runs from vtkmodules.vtkPythonContext2D import * 3. vtkPythonContext2D then tries to load libvtkWrappingPythonCore3.11-9.4.so.1 which fails because that is intended for Python 3.11 but we are using Python 3.13 How that? Well if we check what vtkmodules/vtkPythonContext2D.*.so is linked against we see that it is loading $EBROOTVTK/lib/libvtkPythonContext2D-9.4.so.1 : $ ldd $EBROOTVTK/lib/python3.13/site-packages/vtkmodules/vtkPythonContext2D.cpython-313-x86_64-linux-gnu.so | head -n5 linux-vdso.so.1 (0x00007ffe5a9e5000) libc.so.6 => /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6 (0x00007fae9f053000) libvtkPythonContext2D-9.4.so.1 => $EBROOTVTK/lib/libvtkPythonContext2D-9.4.so.1 (0x00007fae9f047000) libvtkWrappingPythonCore3.13-9.4.so.1 => $EBROOTVTK/lib/libvtkWrappingPythonCore3.13-9.4.so.1 (0x00007fae9effb000) libvtkRenderingContext2D-9.4.so.1 => $EBROOTVTK/lib/libvtkRenderingContext2D-9.4.so.1 (0x00007fae9efac000) [...] (I replaced some long paths with $EBROOTVTK to make it more readable) Now if we look at what libvtkPythonContext2D-9.4.so.1 is linked against, we see: $ ldd $EBROOTVTK/lib/libvtkPythonContext2D-9.4.so.1 | head -n5 linux-vdso.so.1 (0x00007ffd9cdce000) libc.so.6 => /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6 (0x00007effd985f000) libvtkRenderingContext2D-9.4.so.1 => $EBROOTVTK/lib/libvtkRenderingContext2D-9.4.so.1 (0x00007effd9810000) libvtkWrappingPythonCore3.11-9.4.so.1 => $EBROOTVTK/lib/libvtkWrappingPythonCore3.11-9.4.so.1 (0x00007effd97c4000) libvtkRenderingCore-9.4.so.1 => $EBROOTVTK/lib/libvtkRenderingCore-9.4.so.1 (0x00007effd9509000) [...] So we see that $EBROOTVTK/lib/libvtkPythonContext2D-9.4.so.1 is linked against libvtkWrappingPythonCore3.11-9.4.so.1 since it was last compiled against Python 3.11 and that overwrote the file libvtkPythonContext2D-9.4.so.1 that was linked against libvtkWrappingPythonCore3.12-9.4.so.1. Therefore, even though $EBROOTVTK/lib/ should only contain libraries that are independent of a particular Python version, it is hard-coded against the last Python used by our multi_deps = {'Python': ['3.13', '3.12', '3.11']} I really don't see any way how we can provide a single VTK module that works with more than one version of Python, or am I missing something? — Reply to this email directly, view it on GitHub <#93 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFMODOEWKO5MVJBZ5LJOIA33HUNS3AVCNFSM6AAAAABZ2K63JOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANJSG44DENBVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ostueker]

This is a known issue with our VTK and ITK. The libraries gets mixed up on the so to link since we are using multiple pythons. Probably that we should only prodivide the vtk bindings from the wheelhouse and only the lib part from the module.

I'm not quite sure if I understand what you are saying.

After building with multi_deps = {'Python': ['3.13', '3.12', '3.11']} the $EBROOTVTK/lib directory contains:

[user@cluster:${EBROOTVTK}/lib]
$ ls -d *ython*
libvtkCommonPython-9.4.so           libvtkWrappingPythonCore3.11-9.4.so
libvtkCommonPython-9.4.so.1         libvtkWrappingPythonCore3.11-9.4.so.1
libvtkCommonPython-9.4.so.9.4       libvtkWrappingPythonCore3.11-9.4.so.9.4
libvtkFiltersPython-9.4.so          libvtkWrappingPythonCore3.12-9.4.so
libvtkFiltersPython-9.4.so.1        libvtkWrappingPythonCore3.12-9.4.so.1
libvtkFiltersPython-9.4.so.9.4      libvtkWrappingPythonCore3.12-9.4.so.9.4
libvtkPythonContext2D-9.4.so        libvtkWrappingPythonCore3.13-9.4.so
libvtkPythonContext2D-9.4.so.1      libvtkWrappingPythonCore3.13-9.4.so.1
libvtkPythonContext2D-9.4.so.9.4    libvtkWrappingPythonCore3.13-9.4.so.9.4
libvtkPythonInterpreter-9.4.so      python3.11
libvtkPythonInterpreter-9.4.so.1    python3.12
libvtkPythonInterpreter-9.4.so.9.4  python3.13

(the *.so and *.so.1 are symlinks to the corresponding *.so.9.4 lib)

And of course those non-python libs are linked against those libvtkWrappingPythonCore${PythonVersion}-9.4.so* which were built last according to multi_deps.

Sure we can just unmanylinux the VTK-wheels from PyPI and install them into the wheelhouse, but for any VTK-module we'd still have to decide for a single Python version and run with it (whether we'd install the Python-bindings or not).