For anyone discovering this later on who may not be familiar with the command line, here’s how to install the macOS_SDK_headers_for_macOS_10.14.pkg package as explained in @yicongli’s response above:
In Terminal.app or any shell app like iTerm :
cd /Library/Developer/CommandLineTools/Packages/
open macOS_SDK_headers_for_macOS_10.14.pkg
Also on macOS Mojave on a new mac, I had the same issue, but macOS_SDK_headers_for_macOS_10.14.pkg wasn’t there. I got it by downloading and running this from the developer site. Running xcode-select --install might also have worked.
Then I had to fix some tests but then the compile completed.
Slicer runs, but it’s not usable. This is with Qt 5.11.2 on a macbook pro retina, with the resolution set as “best for display”.
This issue of VTK renderer filling up only half of view was a common issue with older VTK versions on MacOS. Interestingly, this issue was recently reported on Surface Pro tablets on Windows and now you see this on MacOS, too.
Maybe it has to do something with switching to native widget as base class? @jcfr do you have idea how to address this?
Yes, but interestingly it isn’t just the VTK windows - the other QWidgets are also messed up. For example in the SampleData module clicking on the MRHead result in loading the DTI example so the display vs event handling geometry is messed up.
BTW the Nightly build works fine on the same machine, so it’s something about the newer Qt and/or the Xcode or OSX deployment target settings.
I see. It may be a different issue then. On Windows, it often takes some time for Qt with catch up with operating system and compiler changes. I guess it could be similar on MacOS, too, and so you can either go back to a bit older toolchain or wait for a new Qt version. Probably many people have reported this issue, so there may be a patch or beta version available already.
Is there anything new on this? I also ran into the same issues on MacOS Mojave where the SliceViews only occupy a small space of what it’s supposed to be.
First Qt had to add support for MacOS Mojave, which should be OK now. Various error reported in other dependencies, such as CMake and VTK. If those are fixed, too, then remaining potential Slicer-specific issues must be addressed. Eventually (in a few weeks or months) things will be sorted out, but if you don’t have time to help out with reporting and investigating issues then it may be simpler to wait it out and use earlier build environment for a while.
Warning: In /Users/herzc/sources/cpp/Slicer/Libs/MRML/DisplayableManager/vtkMRMLThreeDReformatDisplayableManager.cxx, line 99
vtkMRMLThreeDReformatDisplayableManager (0x7faeea1000e0): Widget outline mode not available
Some more details on my environment:
XCode Version 10.1 (10B61)
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
This error is logged when you use VTK7 or older. We have switched to VTK8 long time ago and just keep VTK7 compatibility to allow building with Qt4 + legacy OpenGL rendering backend.
Can you double-check your VTK version by executing print(vtk.vtkVersion().GetVTKVersion())?
If you don’t get VTK version 8.2.0 then double-check your build scripts to make sure you don’t force Slicer to use VTK 7.
You need to set Qt5_DIR before configuring your project as described in build instructions. We’ll disable Qt4/Vtk7 build in the master right after releasing 4.10.1 (within days), which will prevent this error.
FYI: xcode-select --install doesn’t install the headers. You have to install macOS_SDK_headers_for_macOS_10.14.pkg to get the headers. This should be added to the build instructions for Slicer. Where is that now? This page seems pretty out of date now.
@che85: did you also change the version of Qt you were using? Changing vtk version alone cannot fix the huge buttons problem? I’ve had the huge button problem with two other applications I’m working on, one of them not even using vtk. I think it is a problem with the management of retina (hi-dpi) vs. non-retina displays.
I use only Qt binaries from www.qt.io and get the huge button problem on Mojave if I use any version above 5.9.* which was the last LTS version before 5.12. Maybe the 5.12.1 binary fixes the problem but I haven’t tried. The fact that @pieper had success with Qt > 5.9 suggests that there is something in the build process rather than in the version of Qt itself that causes the problem. Perhaps the deployment target? Binaries from qt.io have a minimum osx version of 10.10. Building Qt for 10.14 might fix the problem. Does anybody have better insights into this problem so that we can come up with clear build instructions?
