vtkpython 3.7 error with windows debug build

I’m seeing an error when trying to use vtkpython with python 3.7 and a debug build:

Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit (AMD64)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.

import vtk
Traceback (most recent call last):
File “”, line 1, in
File “D:/akit/vtk/build\bin/Lib/site-packages\vtk.py”, line 32, in
all_spec.loader.exec_module(all_m)
File “D:/akit/vtk/build\bin/Lib/site-packages\vtkmodules\all.py”, line 7, in
from .vtkCommonCore import *
File “D:/akit/vtk/build\bin/Lib/site-packages\vtkmodules\vtkCommonCore.py”, line 2, in
from .vtkCommonCorePython import *
ModuleNotFoundError: No module named ‘vtkmodules.vtkCommonCorePython’

It appears to be because a “_d” is appended to all the compiled libraries in the vtkmodules directory.
A ‘RelWithDebInfo’ build works fine.

I believe that you must use python_d.exe to run using the full debug VTK build, which then forces you to use full debug of all other packages, which, well, good luck…

If you only need the .pdb files so you can get meaningful tracebacks in the debugger, then the RelWithDebInfo build is the way to go.

That makes no sense - why would python force all packages to be debug?
Anyway, it’s something to try, when I get some time. I can make progress using ‘RelWithDebInfo’, so I mostly wanted to report something in case someone else got stuck.

Related MR: https://gitlab.kitware.com/vtk/vtk/merge_requests/5316

Python doesn’t force it, and really has nothing to do with it. This is how Microsoft names debug libraries when you turn on various debug compiler/linker flags.

Python, in debug mode, expects _d suffixes on its module library names. See the code. Windows is just a world where everything is either debug or not debug. The differing runtime libraries between the two configurations requires it. Now, there could certainly be an option to use a release Python with a Debug VTK. That would basically just remove the _d suffix, but if IMPORTED_LOCATION_DEBUG and such are set on the Python3::Python target, we’re going to end up with the debug version anyways.

This is how Microsoft names debug libraries when you turn on various debug compiler/linker flags.

It’s just convention because they are incompatible with each other. There’s nothing forcing a d (or _d suffix) on debug libraries except for it being the common solution to shipping debug and release libraries side-by-side.

What is the recommendation to someone doing a debug VTK+python build on windows, for running scripts? They have to build with a debug version of python? Does it work? (I haven’t had a chance to try it…)

Thanks,

Aron

My approach to debugging on Windows is to use a RelWithDebInfo build, as Eric suggested earlier. But I’m not a Visual Studio afficionado and prefer not to do side-by-side builds, I switched to Ninja many years ago.

I use RelWithDebInfo by default pretty much everywhere due to performance degradation in general. The _d suffix on Windows does require a debug Python right now. It should be shipped with official python.org packages. Not sure about Anaconda. It’s not something that’s been extensively tested though.