- 1 All-in-one Script to checkout and build Slicer3
- 2 Building the 3.6 release
- 3 Building the latest development version
- 4 To run (all platforms):
- 5 Additional Information About getbuildtest and Building Slicer
- 5.1 Testing
- 5.2 What does getbuildtest.tcl do?
- 5.3 Usage
- 5.4 Errors from getbuildtest
- 5.5 Debugging
- 5.6 Updating Your getbuildtest Build
- 5.7 getbuildtest on linux
- 5.8 getbuildtest on Windows
- 5.9 getbuildtest on Apple Mac OS X
- 5.10 getbuildtest on Solaris
- 5.11 configuration options
- 5.12 Changing version numbers
- 6 Building with Qt
- 7 Manual Build
- 8 SBuild
All-in-one Script to checkout and build Slicer3
To compile and build Slicer3, you need a set of development packages installed on your machine:
There's a script called getbuildtest.tcl that makes the support libraries (VTK, ITK, teem, etc) and also builds slicer and does a dashboard submission. (Click here for background on getbuildtest and the experimental getbuildtest2 version).
Building the 3.6 release
For Linux and Mac, just do the following two commands. If you are a Windows user, you need to open a cygwin terminal window and type the commands in that window.
svn co http://svn.slicer.org/Slicer3/branches/Slicer-3-6 Slicer3 ./Slicer3/Scripts/getbuildtest.tcl
For Slicer 3.4 build instructions, please see previous version of this page.
Note that as of August 12, 2011 the Slicer3 trunk requires git to build (in addition to cvs and svn and other dependencies listed below).
Building the latest development version
svn co http://svn.slicer.org/Slicer3/trunk Slicer3 ./Slicer3/Scripts/getbuildtest.tcl
Note: that a Slicer3-lib and Slicer3-build directory will be created for you. This is meant to be used to set up new machines and to run nightly testing of the full builds.
Note: the trunk and 3.6 branches are copies of each other. So there (should be/is) no difference between the two methods described above. See Steve's email (link below) for more information.
To run (all platforms):
Note: the whole build environment takes about 8G of disk space.
Additional Information About getbuildtest and Building Slicer
Note also that getbuildtest will do an Experimental submission to the Slicer3 dashboard. If you want to use getbuildtest without submitting to the dashboard, you can set the test type to nothing with
getbuildtest.tcl -t ""
Other options for the -t (--test-type) option are Nightly or Continuous (or any of the CTest options).
What does getbuildtest.tcl do?
This script just automates the steps needed to build slicer. What you end up with is a set of source and build directories that can either be further manipulated with getbuildtest or can be worked with normally. That is, on windows you will have solution files that you can load in visual studio for debugging and further development.
Specifically, getbuildtest does the following steps:
- Refreshes Slicer3 svn
- Runs Scripts/genlib.tcl which does the following for each of the support libraries
- does a cvs/svn checkout/update
- runs cmake with the correct settings for use with Slicer3
- runs make (or developer studio) to build the libraries
- Runs cmake on Slicer3
- Builds Slicer3
- Runs ctest on Slicer3
- (optionally) Runs CPack on Slicer3
Usage: getbuildtest [options] [target]
[target] is determined automatically if not specified [options] is one of the following: h --help : prints this message and exits -f --clean : delete lib and build directories first -t --test-type : CTest test target (default: Experimental) --release : compile with optimization flags --relwithdebinfo : compile with optimization flags and debugging symbols -u --update : does a cvs/svn update on each lib --no-slicer-update : don't update slicer source (does not effect libs) --build-dir : override default build directory --doc-dir : override default documentation directory --version-patch : set the patch string for the build (used by installer) : default: version-patch is the current date --tag : same as version-patch --pack : run cpack after building (default: off) --pack-dir : where to copy the package after build --upload : set the upload string for the binary, used if pack is true : snapshot (default), nightly, release --doxy : just do an svn update on Slicer3 and run doxygen --verbose : optional, print out lots of stuff, for debugging --rpm : optional, specify CPack RPM generator for packaging --deb : optional, specify CPack DEB generator for packaging -e --extend : optional, build external modules using the extend script -32 -64 : Set if we want to build Slicer 32 or 64 bits : The default on Solaris is the current bitness of the underlying kernel (isainfo -b) : The default on Linux is the current bitness of the underlying kernel : 32 bits on other platforms --gcc --suncc : Set the desired compiler for the build process : The default is gcc/g++
Errors from getbuildtest
You will need to have your firewall configured to allow access to cvs servers through port 2401. Also you need 8081 for submitting to the dashboard.
Other errors might mean you don't have all the build tools (see next section).
If you want to generate a log of the build process, you can use a command like the following:
# for csh/tcsh: ./Scripts/getbuildtest.tcl |& tee build.log
# for sh/bash: ./Scripts/getbuildtest.tcl 2>&1 | tee build.log
Windows: visual studio build messages do not go to stdout/stderr, but each build directory in Slicer3-lib will have a buildlog.txt file with the details.
Since slicer relies on shared libraries, the correct paths must be set up before the debugger can operate (this is accomplished with the Slicer3 Launcher which is in the top level of Slicer3-build). The actual executable entry point (which should not be invoked directly by users) is Slicer3-build/bin/Slicer3-real. The following steps create a shell that has the proper paths set up:
./Slicer3 --launch xterm &
Inside the newly launched window, you can run:
or you can run the debugger of your choice in the new window.
On windows (with rxvt installed via cygwin) the commands are:
./Slicer3 --launch rxvt &
Other tools, such as performance analyzers, memory checkers, etc can also be used in the subshell. Using the launcher is a convenient way to set up the paths for the local build without needing to set any library paths on a system-wide basis. Note that this allows you to have several slicer builds in different directories without having them interfere with one another. The slicer launcher should also allow you to run slicer with it's own local path settings even if you have globally installed versions of VTK, ITK, tcl, python, etc.
More information is available at the links below:
- For information on using the launcher to debug with gdb, see: 
- For debugging with Visual Studio, see: 
- For debugging command line modules, see 
Note you can also debug in XCode with similar methods, but you may need to manually copy the DYLD_LIBRARY_PATH into the project properties (XCode does not seem to inherit from its parent shell).
Updating Your getbuildtest Build
There are a few options:
- you can re-run getbuildtest and it will update slicer3 and rebuild (just slicer3)
- you can add the --update option and all the libs will get a cvs/svn update and will rebuild if needed (good for tracking the development head of VTK/ITK/KWWidgets etc).
- you can just 'svn update' in the Slicer3 directory and then do 'make' in the Slicer3-build to get just the latest Slicer3 code.
The following command for unix machines will update, build, and launch the latest Slicer3:
svn update && (cd ../Slicer3-build; make && ./bin/Slicer3)
Note that on Windows you can also use the CMakeSetup.exe interface to CMake and then use Microsoft Visual Studio for debugging. You can use a command like the following in a cygwin shell to use the slicer launcher to start up visual studio with the correct environment to find the .dll files needed for debugging.
./Slicer3.exe --launch c:/Program\ Files/Microsoft\ Visual\ Studio\ 8/Common7/IDE/devenv.exe --detach Slicer3.sln
getbuildtest on linux
To compile Slicer3 and do development, be sure you have a complete set of development packages installed on your machine. The exact packages vary by distribution, but include:
- libX11-devel (libX11-dev on Ubuntu 7.04)
- libXt-devel (libXt-dev on Ubuntu)
- opengl/mesa (libgl1-mesa-dev on Ubuntu)
- glu (libglu1-mesa-dev on Ubuntu)
Ubuntu one line install:
sudo apt-get install subversion cvs tcl8.4 gcc g++ libX11-dev libXt-dev libxext-dev libgl1-mesa-dev libglu1-mesa-dev libncurses5-dev tcsh git-core
For Ubuntu 11.04 you also need to install libosmesa6-dev with:
sudo apt-get install libosmesa6-dev
CentOS 5.5 (Red Hat) one line install:
yum install subversion cvs gcc-c++ libX11-devel libXt-devel make
You also need git for Centos but it isn't in the standard yum install. One option is to install it using the instructions here.
Fedora 13 required packages as reported by John Drozd:
mesa-demos.i686 7.8.2-1.fc13 updates mesa-dri-drivers-experimental.i686 7.8.2-1.fc13 updates mesa-libGL-devel.i686 7.8.2-1.fc13 updates mesa-libGLU-devel.i686 7.8.2-1.fc13 updates mesa-libGLw.i686 6.5.1-8.fc12 fedora mesa-libGLw-devel.i686 6.5.1-8.fc12 fedora mesa-libOSMesa.i686 7.8.2-1.fc13 updates mesa-libOSMesa-devel.i686 7.8.2-1.fc13 updatesAlso, be sure you have OpenGL and the GLX extension to X working. To check the installation, it is usually enough to confirm that the command
glxgearsruns with no errors.
On occasion, you will encounter a build error relating to the loading of the shared libraries libsvn_fs_util-1.so.0, which are required for the numpy build process. This is due to having a subversion 1.4 or lower installed on your machine. Since this is an optional build in Slicer, you can try building Slicer using these alternatives:
- Turning off python support in the build settings (USE_PYTHON set to "OFF")
- Set the USE_SYSTEM_PYTHON to "true"
As of December 2011, Ubuntu 11.11 requires use of the Slicer3 trunk, not the Slicer-3-6 release branch.
getbuildtest on Windows
The script should work when run from a cygwin terminal window on a properly configured windows environment.
Current requirements are:
- Windows XP, Windows Vista, or Windows 7 operating system (note: Python is disabled by default for non-XP builds due to compilation issues)
- Fast network connection, no firewalls blocking outbound connections (cvs and svn will connect to servers to get source code)
- The build directory shall be on an NTFS formatted disk (CMake and VTK will not work on a FAT formatted disk), with about About 10GB free disk space
- Microsoft Visual Studio with Visual C++ compiler installed
- Install all available service packs for Visual C++
- If they are installed in the default locations in "c:/Program Files" they will be detected by the build script automatically (if they are not installed in the default location or you have multiple compiler versions installed, then you may need to edit slicer_variables.tcl to set the compiler installation path).
- Compiler version:
- Developer Studio 9.0 2008 Visual C++ - this compiler is used to build Slicer3.5 development releases, there are no known limitations
- Developer Studio 9.0 2008 Visual C++ Express (the free version from Microsoft) - see detailed installation instructions here.
- Python will be disabled (only Visual Studio 2008 compiler supported by python 2.6).
- Developer Studio 8.0 2005 Visual C++ - it can be used to build Slicer3.5 with the following limitations
- Python will be disabled (only Visual Studio 2008 compiler supported by python 2.6).
- The compiler randomly crashes during the build (there is no known fix for this problem, just a workround: in case of a crash restart the build)
- Developer Studio 7.1 2003 and older - not tested and may not work
- Cygwin installed - see detailed installation instructions here
- NSIS installed (needed for installation package generation)
- Windows 7 - if you experience random failures during the build process, replace Slicer3-lib/CMake-build with the contents of this zip file: http://www.cmake.org/files/dev/cmake-220.127.116.1100603-g3d1e8-win32-.zip to address these issues with earlier cmake versions: http://public.kitware.com/Bug/view.php?id=10790 and http://public.kitware.com/Bug/view.php?id=10793
- Be sure your visual studio version is fully patched (or random crashes may occur).
- Slicer3 is tested on the English language version of windows. Other languages may cause lead to mysterious build errors. For example, Chinese language for non-Unicode programs (system locale) in Window 7 is known to have problems with KWWidgets.
- Be sure your environment variables for TEMP and TMP are writable by your user account. If the temp variables point, for example, to c:/windows/TEMP then non-administrator account cannot write to it and some build steps will fail. The correct temp paths appear to be: %USERPROFILE%\AppData\Local\Temp for windows 7. Another option is to launch your cygwin shell using the Run As Administrator option.
Follow this link for common errors and troubleshooting on windows.
getbuildtest on Apple Mac OS X
For Mac OS 10.4.10 install the following from the OS disks (not installed by default on new machines):
- Xcode Tools (OS Disk 1, default window)
- X11: also on OS Disk 1, but you need to scroll down and find the Optional Installs installer and select X11 under Applications. See step-by-step instructions.
- X11SDK - from OS Disk 1, Xcode Tools/Packages/X11SDK.pkg
- Subversion. Installation options here. Get the latest svn version for compatibility with the server and be sure your client includes SSL (so it can access https repositories).
Remember to run getbuildtest from an xterm so the tests can access the X server.
Note: The Apple X11 application on Mac OSX 10.5.x (Leopard) crashes frequently. We suggest you replace the default XX with XQuartz.
If you come across the link error
dyld: Library not loaded: libvtksys.5.6.dylib
Set the flag VTK_USE_RPATH=ON (see the post here)
For the latest version of Mac OS X (10.7) the correct X11 comes pre-installed.
As of December 2011, only Slicer3 trunk compiles on 10.7 (not the Slicer-3-6 branch). Also python is not correctly compiled on 10.7 so it should be disabled by editing the Slicer3_USE_PYTHON option in slicer_variables.tcl
getbuildtest on Solaris
Collaboration with the University of Szeged in Hungary has resulted in a port of slicer3 to the current generation of the Oracle (formerly Sun) Solaris operating system. More information, including binary downloads, is available at the Slicer3 Solaris page.
The file Slicer3/slicer_variables.tcl includes configuration options for which versions of support libraries to use. You may want to change these for testing or to get access to new functionality.
These flags control the versions of code pulled from external repositories:
set ::Slicer3_TAG "http://svn.slicer.org/Slicer3/trunk" set ::CMAKE_TAG "CMake-2-6" set ::KWWidgets_TAG "Slicer-3-2" set ::VTK_TAG "VTK-5-2" set ::ITK_TAG ITK-3-6 set ::PYTHON_TAG "http://svn.python.org/projects/python/branches/release25-maint"
Other libraries, such as Tcl/Tk, teem, and curl, together with windows binaries for CMake and Tcl/Tk are mirrored for efficiency at http://svn.slicer.org/Slicer3-lib-mirrors.
For example, you may want a build against the ITK cvs head. Change the flag value and then run
which will get the version from cvs, build it, and rebuild slicer3. Depending on how radically different the versions you build are, you may need to use the --clean option which will delete all build directories and rebuild.
Changing version numbers
Click here for the checklist of things to do when branching svn and creating a new Slicer release.
Building with Qt
If you start with an already built slicer, you can add Qt to the build. As of fall 2009 this is still very much a work in progress and the details are expected to change.
You can also build Slicer without using getbuildtest.tcl. For more information about manually compiling Slicer, see this page.
SBuild is a new, experimental build system for Slicer. For more information about SBuild, see the SBuild page.