Building on Mac 10.14 Mojave


(Hans Johnson) #1

After running into:

./cryptlib.h:62:11: fatal error: 'stdlib.h' file not found
# include <stdlib.h>
          ^~~~~~~~~~
1 error generated.

I found: https://github.com/frida/frida/issues/338#issuecomment-426777849

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

(Steve Pieper) #2

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”.


Ubuntu 18.04 scaling small issues
(Andras Lasso) #3

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?


(Steve Pieper) #4

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.


(Andras Lasso) #5

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.


(Steve Pieper) #6

Yes, I’m sure it’ll be sorted out. Just need to look at what might be leading to the differences or wait for bugs to be fixed upstream.

I tried recompiling with CMAKE_OSX_DEPLOYMENT_TARGET set to 10.`14 but no difference.


(Christian Herz) #7

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.

Or is there maybe a workaround?


(Andras Lasso) #8

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.


(Steve Pieper) #9

FWIW, I installed the homebrew Qt5 environment and rebuilt on the Mojave mac laptop and the rendering issues went away.


(Jean Christophe Fillion Robin) #10

Interesting, the recipe use to create the corresponding Qt5 package seems to be quite normal, see https://github.com/Homebrew/homebrew-core/blob/master/Formula/qt.rb

As a side note, when building on macOS, the variable Qt5_DIR and CMAKE_OSX_DEPLOYMENT_TARGET must be specified when doing a clean configuration.


(Andras Lasso) #11

Which Qt version did you use?


(Steve Pieper) #12

Both home brew and the Qt download were 5.11 (both 5.11.2 I believe).


(Christian Herz) #13

I used 5.10 and it didn’t work. Will try with brew and 5.11 again.