I just tried Slicer 3D master branch clean build on Windows 11, VS 2022 and I get error:
Performing install step for 'SimpleITK'
-- SimpleITK: Removing 'install' log files
-- SimpleITK: SimpleITK_WORKING_DIR: C:/C/r/SimpleITK-build/SimpleITK-build/Wrapping/Python
-- SimpleITK: C:/C/r/python-install/bin/PythonSlicer.exe;setup.py;install
-- SimpleITK: Errors detected - See below.
CMake Error at C:/C/r/slicersources-src/CMake/ExternalProjectForNonCMakeProject.cmake:104 (message):
SimpleITK: install step failed with exit code '1'.
Outputs also captured in C:/C/r/SimpleITK_install_step_output.txt and
C:/C/r/SimpleITK_install_step_error.txt.
Setting env. variable EP_EXECUTE_DISABLE_CAPTURE_OUTPUTS to 1 allows to
disable file capture.
Call Stack (most recent call first):
C:/C/r/SimpleITK_install_step.cmake:3 (ExternalProject_Execute)
Traceback (most recent call last):
File "C:\C\r\SimpleITK-build\SimpleITK-build\Wrapping\Python\setup.py", line 14, in <module>
from SimpleITK._version import __version__
File "C:\C\r\SimpleITK-build\SimpleITK-build\Wrapping\Python\SimpleITK\__init__.py", line 18, in <module>
from SimpleITK.SimpleITK import *
File "C:\C\r\SimpleITK-build\SimpleITK-build\Wrapping\Python\SimpleITK\SimpleITK.py", line 13, in <module>
from . import _SimpleITK
ImportError: DLL load failed while importing _SimpleITK: The specified module could not be found.
I guess some _SimpleITK’s dependencies not found.
There is no such problem on Ubuntu
It is almost always due to some invasive Python environment, which got added to the system PATH or other environment variables. See some more information and solution here: Windows — 3D Slicer documentation
If the solution described there does not work then please copy here the error messages that the build output refers to.
No I don’t have any other python installed and Windows is almost clean (installed it yesterday as virtual machine).
Do you mean the content of C:/C/r/SimpleITK_install_step_output.txt and C:/C/r/SimpleITK_install_step_error.txt files?
If so then SimpleITK_install_step_output.txt is empty now and SimpleITK_install_step_error.txt contains the same error:
Traceback (most recent call last):
File "C:\C\r\SimpleITK-build\SimpleITK-build\Wrapping\Python\setup.py", line 14, in <module>
from SimpleITK._version import __version__
File "C:\C\r\SimpleITK-build\SimpleITK-build\Wrapping\Python\SimpleITK\__init__.py", line 18, in <module>
from SimpleITK.SimpleITK import *
File "C:\C\r\SimpleITK-build\SimpleITK-build\Wrapping\Python\SimpleITK\SimpleITK.py", line 13, in <module>
from . import _SimpleITK
ImportError: DLL load failed while importing _SimpleITK: The specified module could not be found.
I don’t know maybe the content of these files were changed while I was trying to repeat installation by modifying setup.py to discover the error and running it with command (as it is done in External_SimpleITK.cmake):
It is typically not worth spending time with manually altered builds. Instead, delete your entire build tree and restart the build from scratch. It is very important to not do any manual configuration in CMake but configure and start your build using a .bat file to make sure that you can anytime rebuild Slicer from scratch with a single click of a button.
This indicates that you had an error earlier during the build. You’ll do a clean build form scratch anyway, so preserve that build log and search for the first error. I usually do that by searching for : err in the full build log.
HDF5 is the library that most commonly breaks ITK build. It is always a huge pain. I’m not surprised that it broke your build, too.
If this solves all your problems and this workaround is acceptable for you then it is good. I’m not sure if this is the cleanest solution, but if you submit a pull request then I’m sure that at some point @jcfr can have a look at it and merge it if there are no better ideas.
Sometimes to solve my issues I need to modify Slicer’s External_smth.cmake.
In this case I prepare modified by me External_smth.cmake (in SlicerCAT/CMake dir) and during configuration time I copy this file to slicersources-src/SuperBuild/External_smth.cmake thus replacing Slicer’s original file:
I can’t do this know (I’m sorry) but in the future some of those dirty solutions should be implemented as a PRs (like with HDF5).
Just in case some of my propositions (for the future):
either build HDF5 as external project or add an opportunity to find HDF5 through HDF5_ROOT (probably easier to handle HDF5 versions) var (requires to modify VTK and ITK ext projects). Modified External_VTK.cmake and External_ITK.cmake
ITK uses Eigen as third party libs. Add mark_as_superbuild Eigen3_INCLUDE_DIR to ITK ext project to link to Eigen. Because if some of ext proj also downloads Eigen and these Eigen libs are of different versions then you may face a problem when the compiled lib uses different Eigen libs in the same function for example. It is difficult to trace (I encountered that)
sqlite is very popular library and it should be built as shared library. It is pretty often that sqlite is a dependency of some project. For now only python uses sqlite. Just in case I prepared shared sqlite project (probably it could be done a little cleaner but it works) and the modified External_sqlite.cmake. And probably sqlite should better be renamed to SQLite3 as CMake prefers
HDF5 is so messed up, build errors and ABI incompatibilites caused so much pain for ITK developers that they now just build it internally, using a custom prefix to isolate it from all external implementations.
Anyway, if you want to open this can of worm then you can put an External_HDF5.cmake into the Superbuild folder and set Slicer_USE_SYSTEM_HDF5=ON. It looks like Slicer automatically forwards this as USE_SYSTEM_HDF5=ON to all external projects.
In general, well-behaving libraries, such ITK, VTK, etc. build their own dependencies (such as Eigen, SQLite, HDF5, …) and don’t leak them out on public APIs, or if they do then they use custom prefixes in symbol names and DLL names to avoid any interference with all the other instances of these common libraries.
A popular library typically cannot be built as a shared library due to API and ABI incompatibility issues. If it is a small library, such as SQLite, then the simplest is to just build it as a static library. If it is a huge and complex library, such as HDF5, then it may worth building it as a shared library - but then symbol names and shared library names require a custom prefix to ensure that many different versions can coexist.
Regarding to the Slicer project I expect there most likely should not be ABI issues with generic libs like SQlite, HDF5 as we build everything at once.
In my case I needed to install PROJ and GDAL libs and they require SQlite. As I remember I couldn’t build them with static SQlite.
Current Slicer uses ITK v5.3rc03 wich uses latest Eigen 3.4 but before that ITK used Eigen 3.3 and I had external project Eigen 3.4
I encountered a situation described above: in the same function I had two eigen versions worked differently
But I completely understand everything you said and probably in some cases SlicerCAT developers should be ready for things like that
Sometimes you cannot build everything yourself. For example, extensions can install Python wheels, or you may use some SDKs that contain pre-built binaries.
Sometimes your various software components require different versions of the same library, so you cannot build and use a single version everywhere.
