Transition of nightly build to Qt5, VTK9, CMake 3.9 and C++11

Hi All,

Now that we have released Slicer 4.8.1 and also addressed a lot of issues with Qt5 and VTK9, the time has come to transition our nightly builds.

IMPORTANT: Time the nightly builds are stabilized, you should expect disruption and build failures until the end of next week.

Transition Plan

Later this week and the following one, we will:

Important remarks

  • waiting we transition Linux build from Ubuntu 10.04 VM running on factory-south.kitware to docker or VM based build running on metroplex.kitware dashboard, we will keep linux build with Qt4 and VTK7. This will happen later.

Very Exciting! You may want to speak with Matt McCormick regarding minimum OSX versions. He just completed an investigation into this regarding ITK and python.

Very exciting indeed! With the transition to VS2015, will the python version also be changed to 3.5 or will this be done at a later date?

Python 3 migration is planned, too. As far as I know, most or all Slicer dependencies support Python 3 already, so the switch could probably happen later this year, once Slicer is stabilized after VTK, Qt, and compiler updates.

1 Like

To complement @lassoan answer, during the past few years we worked hard to update VTK and ITK to work nicely with Python 3. Now that PythonQt also support it. The remaining part will be to update CTK and Slicer to work with Python 3.

If this is something important for your project and you have resources to allocate for this, do not hesitate to reach out to me.

1 Like

No rush, more of a personal interest :wink:

ok, great! waiting for the Linux transition as well :yum::smile:

1 Like

That will come last but we will make sure to keep you posted of the progress.


1 Like

Windows nightly build for Slicer application and extensions have been updated to use VS2015.

Tomorrow, we will update the windows script to use Qt5 and VTK9 (as well as OpenGL2)


  • Windows build machine (named overload) has been updated two days ago but Slicer build failed because the dashboard script wasn’t setting Qt5_DIR. This was fixed yesterday in Slicer/DashboardScripts@3d50b85.
  • On that same machine, StrawberryPerl was also installed yesterday to generate archives of pre-built libraries for a recent version of OpenSSL and upload them on
    • This caused the last nightly build to fail (see below) because the patch.exe provided by StrawberryPerl failed to be used to patch NUMPY.
    • This was addressed by removing the extra path
    • Note that corresponding CDash entry was removed, and nightly build was restarted.

Error that was reported on the dashboard:

Program: C:\StrawberryPerl-x64\c\bin\patch.exe

File: .\src\patch\2.5.9\patch-2.5.9-src\patch.c, Line 354
Expression: hunk

It was originally available at but corresponding entry was deleted, and build was manually restarted.


@jcfr Will the official Qt version be 5.10.0, or it hasn’t been fixed yet?

Since Qt 5.10.0 addresses issues (especially with WebEngine), I think we should go with it for the current release cycle. We could then revisit after Slicer 5.0 is out.

1 Like


1 Like

FYI the popup problem already had an issue:

It’s great that the official Slicer at least for windows is now Qt5. Thanks for working on this!

1 Like


  • Thanks to @hina-shah , Slicer issue #4503 is now fixed.

  • macOS:

    • Starting today, Slicer packages for macOS will be done on factory-south.kitware using Qt5 and VTK9 with OpenGL2 enabled.
    • Deployment target will be 10.9, this means Slicer nightly package will NOT run on older operating system.
    • qt-easy-build scripts for macOS and Linux have been updated to support building Qt 5.10.0 without rpath. (Corresponding CircleCI and TravisCI are green)
  • windows:

    • today’s Windows packages have successfully been built using VS2015, VTK9, Qt5 and C++11

Next Steps

Listed in no particular order

  • Fixes for the startup warnings related to the extension manager ( should be integrated later today.
  • Address remaining styling issues (thanks to @hjmjohnson ) and warnings
  • Update of the wiki (Note that I already have screenshot documenting the step to install Qt 5.10.0 on Windows)
  • Setup Linux build
  • Tag sources and integrate changes in project like Slicer/itkMGHImageIO (thanks to @hjmjohnson)
  • Update minimum version of CMake to 3.9.5

More details

Why Qt5 needs to build without rpath on macOS ?

This is required to work well with the current implementation of the packaging system.

The good news is that @ihnorton is working on creating a python script that will greatly speed up the packaging process and also allow repackaging of Qt libraries installed using official installer.

Was the build of Slicer against Qt 5.10.0 and VTK9 tested on macOS ?

During the past year, a lot of people contributed to testing and stabilizing the build.

Last night, new dashboard scripts were added to support building on factory-south-macos:

Build of the Slicer application was manually started (with packaging disabled), it failed with an error related to Swig installation that should be fixed in r26877

Later today, the build was manually restarted and it completed. Packaging is now in progress, and I think it will succeed. If not, that will give us the opportunity to fix problem before the nightly start.

1 Like


Alas no, it crashed on startup; log below.

Process: Slicer [58842]
Path: /private/var/folders/*/
Identifier: Slicer
Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Slicer [58842]
User ID: 501

Date/Time: 2018-02-02 18:34:05.285 -0500
OS Version: Mac OS X 10.13.3 (17D47)
Report Version: 12
Anonymous UUID: AE9D173E-A1E8-E500-62F7-C31D0E540E6E

Time Awake Since Boot: 260000 seconds

System Integrity Protection: enabled

Notes: Translocated Process

Crashed Thread: 0 Dispatch queue:

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue:
0 libsystem_kernel.dylib 0x00007fff6eb8ce3e __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff6eccb150 pthread_kill + 333
2 libsystem_c.dylib 0x00007fff6eae9312 abort + 127
3 org.qt-project.QtCore 0x000000011999d9a9 0x119987000 + 92585
4 org.qt-project.QtCore 0x000000011999f239 QMessageLogger::fatal(char const*, …) const + 233
5 org.qt-project.QtGui 0x000000011949e866 QGuiApplicationPrivate::createPlatformIntegration() + 5670
6 org.qt-project.QtGui 0x000000011949e88b QGuiApplicationPrivate::createEventDispatcher() + 27
7 org.qt-project.QtCore 0x0000000119b7fbd5 QCoreApplicationPrivate::init() + 2069
8 org.qt-project.QtGui 0x000000011949a320 QGuiApplicationPrivate::init() + 64
9 org.qt-project.QtWidgets 0x0000000118ed585a QApplicationPrivate::init() + 26
10 libqSlicerBaseQTCore.dylib 0x000000010abec7f0 qSlicerCoreApplication::qSlicerCoreApplication(qSlicerCoreApplicationPrivate*, int&, char**) + 32
11 libqSlicerBaseQTGUI.dylib 0x000000010a2f8188 qSlicerApplication::qSlicerApplication(int&, char**) + 200
12 0x0000000109f980f3 (anonymous namespace)::SlicerAppMain(int, char**) + 803
13 libdyld.dylib 0x00007fff6ea3d115 start + 1

Also there’s no slicer icon.


When I try opening from the console I get this message that indicates it’s not finding the platform library in spite of it being installed by r26882. Odd that it says it can’t find “cocoa” but also says that “cocoa” is available. Is it maybe the wrong version of the platform library file?

$ /Volumes/Slicer-4.9.0-2018-01-28-macosx-amd64/ 
This application failed to start because it could not find or load the Qt platform plugin "cocoa"
in "".

Available platform plugins are: cocoa.

Reinstalling the application may fix this problem.
Abort trap: 6

There a number of RPATH problems masked behind the qt plugin loader. inorton$ QT_DEBUG_PLUGINS=1 ./Contents/MacOS/Slicer
QFactoryLoader::QFactoryLoader() checking directory path "/private/tmp/" ...
QFactoryLoader::QFactoryLoader() looking at "/private/tmp/"
Found metadata in lib /private/tmp/, metadata=
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
    "className": "QCocoaIntegrationPlugin",
    "debug": false,
    "version": 330240

Got keys from plugin meta data ("cocoa")
QFactoryLoader::QFactoryLoader() checking directory path "/private/tmp/" ...
Cannot load library /private/tmp/ (dlopen(/private/tmp/, 133): Library not loaded: /Volumes/Dashboards/Support/qt-everywhere-build-5.10.0/lib/QtGui.framework/Versions/5/QtGui
  Referenced from: /private/tmp/
  Reason: image not found)
QLibraryPrivate::loadPlugin failed on "/private/tmp/" : "Cannot load library /private/tmp/ (dlopen(/private/tmp/, 133): Library not loaded: /Volumes/Dashboards/Support/qt-everywhere-build-5.10.0/lib/QtGui.framework/Versions/5/QtGui\n  Referenced from: /private/tmp/\n  Reason: image not found)"
This application failed to start because it could not find or load the Qt platform plugin "cocoa"
in "".

Available platform plugins are: cocoa.

Reinstalling the application may fix this problem.
Abort trap: 6

Could try the latest nightly for macos. I manually fixed and triggered the
upload this morning.