delvewheel is detecting bitness problems when Visual Studio is loaded into the environment. Is there a way to skip over the first name-matching DLL and continue searching for a matching bitness candidate before bailing on the first name (which ends up being unsuitable)?
$ delvewheel show (Get-ChildItem dist\*.whl | % FullName)
Analyzing vtk-9.0.20210427-cp36-cp36m-win_amd64.whl
Traceback (most recent call last):
File "C:\glr\builds\vtk\vtk-ci-ext\0\.gitlab\python\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:\glr\builds\vtk\vtk-ci-ext\0\.gitlab\python\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\glr\builds\vtk\vtk-ci-ext\0\build\venv\Scripts\delvewheel.exe\__main__.py", line 9, in <module>
File "c:\glr\builds\vtk\vtk-ci-ext\0\build\venv\lib\site-packages\delvewheel\__main__.py", line 67, in main
wr.show()
File "c:\glr\builds\vtk\vtk-ci-ext\0\build\venv\lib\site-packages\delvewheel\wheel_repair.py", line 302, in show
discovered, ignored, not_found = patch_dll.get_all_needed(extension_module_path, self._add_dlls, self._no_dlls, self._wheel_dirs, 'ignore')
File "c:\glr\builds\vtk\vtk-ci-ext\0\build\venv\lib\site-packages\delvewheel\patch_dll.py", line 145, in get_all_needed
raise OSError(f'Dependent library {lib_path} is {lib_bitness}-bit but Python interpreter is {interpreter_bitness}-bit')
OSError: Dependent library c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\concrt140.dll is 32-bit but Python interpreter is 64-bit
delvewheel
is detecting bitness problems when Visual Studio is loaded into the environment. Is there a way to skip over the first name-matching DLL and continue searching for a matching bitness candidate before bailing on the first name (which ends up being unsuitable)?Full output log (unsure of how long this sticks around): https://gitlab.kitware.com/vtk/vtk/-/jobs/5743222#L3474
Relevant output: