I ran “make clean” and got the same results. Successful build but the same runtime error.
Let me know if there is something I should try. Thanks!
I ran “make clean” and got the same results. Successful build but the same runtime error.
Let me know if there is something I should try. Thanks!
Are you running macOS 27 Golden Gate which is yet to be publicly available in stable build form? The current set of dependencies that Slicer uses is not yet guaranteed to work for macOS 27 though they do generally get fixed up sometime after the stable release is out. I have built latest Slicer main on macOS 26 Tahoe successfully with homebrew provided 6.11.2 and CMake 4.3.
I am running the developer betas and that could be the problem. I don’t want to waste your time; thanks for your help!
I installed Tahoe 26.6.2 so that I can get Slicer to build properly. I am following the Recipe for MacOS on arm64. When trying to build Slicer, i get an error message “PythonSlicer: Bad CPU type in executable. The CPU type is x86_64. Any idea what went wrong?
cmake \
-DQt5_DIR:PATH=/opt/homebrew/opt/qt@5/5.15.19/lib/cmake/Qt5 \
-DCMAKE_OSX_ARCHITECTURES:STRING=arm64 \
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=14.0 \
-DCMAKE_OSX_SYSROOT:PATH=$(xcrun --sdk macosx --show-sdk-path) \
-DCMAKE_BUILD_TYPE:STRING=Release \
-B ./S5R \
-S ./Slicer
cmake --build ./S5R -j 10
^I’m usually doing something like the following to build from command line. Are you doing something similar?
Hello James,
I have been following the recipe in the documentation for building for MacOS on Apple silicon… a little too blindly, because I noticed, when looking at the build script, that DICOM support was turned off (doh!). So now, it built on Golden Gate but doesn’t on Tahoe 26.6.2 (at the moment for me).
I am also using Qt6 (vs Qt5 in your example below) . I will try what you do on Tahoe (with Qt6) to see what happens.
BTW, it is interesting to compare performance differences between building on both OSes. I get the impression, without actually measuring, that things run faster on Tahoe (perhaps because Golden Gate still is Beta code and not optimized yet)
Thanks for your help!
Gene
Last night, I tried building Slicer with “TBB”. It appears to be working!
Extensions do not load directly; I suspect a “macOS-arm64” version of the files is needed.
FWIW: I downloaded a few extensions and tried to install them as files. For “TotalSegmentator” I get “no GPU is detected”.
Running the x86_64 version (under MacOS) also gives “no GPU is detected”
@jamesobutler Final update for today: I edited TotalSegmentator.py to enable MPS. I also had to force ‘torchvision’ to load. Once I did that, Slicer runs TotalSegmentator with the Metal shaders successfully on my CT data!
I also left ‘TBB’ on in the build.
Gene
You specifically modified the following lines below?
Cc @lassoan regarding arm64 updates for the TotalSegmentator extension
Yes, in my locally built copy (in Slicer.app).
@jamesobutler I installed the latest MacOS 27 and decided to rebuild. I think my old build is somehow influencing the next build. When I look at availability extensions (the day after I do a new build) TotalSegmentator and the others I loaded are not even shown. They are in the list for Windows and Linux.
How do I wipe the slate clean when doing a new build?
Thanks!
Gene
The extension manager is currently not providing any arm64 compiled extensions so I would suggest not expecting to rely on that for getting code. Yes, the python based extensions could be used, but not all extensions.
In general when individuals have built Slicer from source, they are expected to build extensions from source as well. The revision where you might’ve built for macOS, may not match the exact revision number that the Slicer factory built. Also Slicer factory’s macOS extensions are known to be available much later in the day compared to the Windows and Linux extensions which finish and are published much earlier. This is a constraint of the old intel mac machine currently in use by the Slicer factory.