CMake

It is difficult to create distributable executables for Linux because of issues like incompatible C libraries and C++ standard libraries. Creating static executables can help with this portability. Static builds are useful for other important ... [More] platforms, as will be discussed in future posts. ITK Git master recently added support for building static executables.  In this post, we will describe how to build static executables against ITK.   When configuring ITK, use the following options: cmake \   -DBUILD_SHARED_LIBS=OFF \   -DITK_DYNAMIC_LOADING=OFF \   ~/src/ITK The BUILD_SHARED_LIBS option tells CMake to build static libraries instead of shared libraries, which can be linked into the static executable. Also, the ITK_DYNAMIC_LOADING option disables ITK's ability to load libraries at runtime into its object factory -- this requires dynamic loading.   When building executables against ITK, use the following configuration,   cmake \     -DITK_DIR=/path/to/static/ITK \     -DCMAKE_EXE_LINKER_FLAGS="-static" \     -DCMAKE_FIND_LIBRARY_SUFFIXES=".a" \     ~/src/BuildAHelloWorldProgram The -static flag is passed to the linker so it will create a static executable instead of a dynamically linked executable. The CMAKE_FIND_LIBRARY_SUFFIXES variable will ensure that CMake only finds static libraries, which end it .a. In this case, it is not strictly necessary since we only built ITK with static libraries. When we examine the executable created from a dynamic build: $ file BuildAHelloWorldProgram BuildAHelloWorldProgram: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.12.0, not stripped $ du -sh BuildAHelloWorldProgram 124K    BuildAHelloWorldProgram we see that it is dynamically linked and uses an interpreter, i.e. the dynamic loader, /lib64/ld-linux-x86-64.so.2.  The file size is 124 kilobytes.   And the executable created from a static build: $ file BuildAHelloWorldProgram BuildAHelloWorldProgram: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.12.0, not stripped $ du -sh BuildAHelloWorldProgram 6.0M    BuildAHelloWorldProgram In this case, the executable is statically linked. The disadvantage to statically linked executables is their size -- 6.0 megabytes versus 124 kilobytes.   Enjoy ITK! [Less]

Continuing our series on cross-compiling ITK with CMake and Docker, we will cross-compile for the POWER8, which is a PowerPC 64 little endian system, i.e. ppc64le.  This entry follows articles on cross-compiling for Windows and the Raspberry Pi with ... [More] Docker. The POWER8 is interesting because it is a highly parallel system, running 8 threads on each core with up to 12 cores per chip. By cross-compiling, we can test patches that address dashboard build warnings so we can have a working system on which to perform parallel performance benchmarking. When cross-compiling with Docker and CMake, there are three basic steps. 1) Get the cross-compiling toolchain Obtaining the toolchain with Docker is easy -- just download it with docker pull: docker pull thewtex/cross-compiler-linux-ppc64le    2) Start up a container, mounting the source and build tree If there is a source tree and build tree, e.g. cd ~/src git clone http://itk.org/ITK.git mkdir -p ~/bin/ITK-build Then mount these directories as Docker volumes when the container is started: docker run --rm -it \   -v ~/src/ITK:/usr/src/ITK:ro \   -v ~/bin/ITK-build:/usr/src/ITK-build:rw \   thewtex/cross-compiler-linux-ppc64le   3) Point CMake to the CMAKE_TOOLCHAIN_FILE Inside the container, the environmental variable CMAKE_TOOLCHAIN_FILE has been configured to point to the toolchain file CMake uses to inform itself about the build environment.  Pass this file to CMake during configuration. cd /usr/src/ITK-build cmake -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} ../ITK make -j$(nproc)   Enjoy! [Less]

Cross-compilation process evolution In previous posts, Luis taught us how to cross-compile for the Raspberry Pi. In this post, we'll discuss an evolved approach for cross-compiling for the Raspberry Pi and Raspberry Pi 2. The ... [More] cross-compiling process for this ARM platform from an x86_64 host is now greatly simplified. Also, we can now run the test suite! wOOt! While cross-compiling, the following improvements are notable, some of which are specific to ITK. 1) The toolchain is a single command away As discussed in a previous post, Docker is a great, cross-platform way to download and run pre-built and configured toolchains.   2) No need to populate a Toolchain.cmake file Since we used a Docker image that is pre-configured with its own toolchain file, we only need to do is pass CMake the path to this single file, and CMake is informed of all it needs to know about the toolchain.   3) No need to populate a TryRunResults.cmake file CMake gets information specific to the target system with the try_run command. When cross-compiling, access to the target system is not available. By default, CMake will output a TryRunResults.cmake that must be populated by transferring the try_run executables over to the target system, running the commands, and entering the output and return value in this file. This file must then be transferred back to the build host, and then the TryRunResults.cmake are read by CMake before the build process can be continued. In this case, this entire process is now avoided when a CMAKE_CROSSCOMPILING_EMULATOR is configured in the toolchain file. This emulator is used to run the try_run executables, and the build configuration process proceeds automatically without any user intervention required. The QEMU user-mode emulator is applied for this task.   4) No need for TIFF and HDF5 workarounds ITK has been improved so the internal third-party library builds of TIFF and HDF5 no longer require manual intervention.   5) Build all the things All the default ITK modules, and their tests, now build without issue.   6) Run the test suite The test suite can also be run on the build host. CMAKE_CROSSCOMPILING_EMULATOR will be used to run all tests that use executables built for the target system.   7) No Pi required We don't actually need a physical Raspberry Pi to develop for one.   Get the cross-compiler If Docker is installed, download the cross-compiler image. This cross-compiler with work will both the Raspberry Pi and the Raspberry Pi 2, even though Raspberry Pi is ARMv7. docker pull thewtex/cross-compiler-linux-armv6   Get the code Download the ITK source tree if it not already available, and create a build directory: cd ~/src git clone http://itk.org/ITK.git mkdir -p ~/bin/ITK-build   Build and test! Start up a docker container, and mount the source and build directories as volumes in the container: docker run --rm -it \ -v ~/src/ITK:/usr/src/ITK:ro \ -v ~/bin/ITK-build:/usr/src/ITK-build:rw \ thewtex/cross-compiler-linux-armv6 The --rm flag tells Docker to remove the image after we exit. The -it flag tells Docker to start up an interactive terminal. Our Docker image is configured to drop us into a new bash shell by default. Next, clear the build tree and configure the build: cd /usr/src/ITK-build rm -rf * cmake \ -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} \ -DBUILD_EXAMPLES=OFF \ -G Ninja \ ../ITK The Docker image is configured to set the path to the toolchain file in the CMAKE_TOOLCHAIN_FILE environmental variable. We set BUILD_EXAMPLES to OFF because the test driver executable, used to test the examples, spawns a process to run the example. QEMU does not currently support this, even though the examples build fine. We also tell CMake to use our favorite generator, Ninja. Next, we will run an Experimental ctest build. CTest does a CMake configuration, executes the build, runs the tests, and submits the results to the CDash dashboard. QEMU user-mode currently is limited in its multi-threading capabilities, so run the tests in single-threaded mode by setting the ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS environmental variable: export ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS=1 ctest -j $(nproc) -D Experimental   Create applications We can build applications against ITK in a similar way. To build this example: wget http://itk.org/ITKExamples/src/Core/Common/BuildAHelloWorldProgram/BuildAHelloWorldProgram.tar.gz tar xvzf BuildAHelloWorldProgram.tar.gz cd BuildAHelloWorldProgram/build cmake \ -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} \ -DCMAKE_BUILD_TYPE=Release \ -DITK_DIR=/usr/src/ITK-build \ .. ninja   Happy hacking! [Less]

ITK Git master has reached a major milestone -- Python wrapping now builds and cleanly passes tests on the default compilers for MacOSX, Linux, and Windows! Python bindings make the extensive library of scientific image analysis algorithms embodied ... [More] in the Insight Toolkit available to the rich scientific Python ecosystem. The ITK bindings complement excellent Python wrappings already available for SimpleITK, the simplified API for the Insight Toolkit. Python wrapping allows for rapid prototyping via an accessible language for researchers. Green ITK Python wrapping goodness. A number of people have made the green wrapping goodness possible. Michka Popoff has spearheaded the cleanup effort.  Kevin Hobbs and Bradley Lowekamp made sure there were Nightly dashboard builds on which to improve. Gaëtan Lehmann engineered the current CMake and SWIG-based wrapping infrastructure, WrapITK, and brought it into the repository build system. Brad King wrote CastXML (C-family Abstract Syntax Tree XML Output), the next generation, Clang-based replacement for GCCXML, which is used to parse the C++ abstract syntax tree. This work was supported by funding from the National Institutes of Health-National Library of Medicine (NIH-NLM). To build the wrapping, enable ITK_WRAP_PYTHON in your CMake configuration. To test the wrapping without installation, copy the Wrapping/Generators/Python/WrapITK.pth file to Python's site-packages directory. Windows users should also add the bin build directory containing the DLL's to their PATH environmental variable. Enjoy ITK!   [Less]

GCC 5.1 was recently released!1 Following a contributed patch, ITK now builds against GCC 5.1, although there are still some issues to be addressed. Previously, we wrote about how to use Docker to get easy access to cross-compiling toolchains. GCC ... [More] also hosts official Docker images, so we can also easily test out new GCC versions. Here are the steps to do an Experimental build of ITK. docker pull gcc:5.1 cd ~/src/ git clone git://itk.org/ITK.git mkdir -p ~/bin/ITK-build docker run --rm -it \   -v ~/src/ITK:/usr/src/ITK:ro \   -v ~/bin/ITK-build:/usr/src/ITK-build:rw \   gcc:5.1 cd /usr/src/ITK-build apt-get update && apt-get install -y cmake export MAKEFLAGS=-j$(nproc) cmake ../ITK && ctest -D Experimental   1 Where did GCC 5.0 go? The versioning scheme has changed. [Less]

In the past, cross-compiling was often an art that required a Unix beard, a considerable amount of time, and a chicken to sacrifice. Assembling the cross-compiler toolchain was often a lengthy manual configuration process that was, at best, poorly ... [More] documented. A number of recent projects make cross-compilers more readily available, but they still usually only work on a few versions of select Linux distributions. Docker images make cross-compiling toolchains easily accessible from any recent Linux distribution and even MacOSX and Windows. When combined with CMake, which has very good cross-compilation support, it is easy to take C/C++-based code and build it for almost anything. Previously, we described how to build ITK code for Windows from a Debian Jessie Linux distribution. While building the cross-compiler was relatively straight forward, we can get the toolchain with one simple command on any host with Docker installed: docker pull thewtex/cross-compiler-windows-x86 To perform an Experimental dashboard build with the source code cloned at ~/src/ITK: docker run --rm -it -v ~/src/ITK:/usr/src/ITK:ro thewtex/cross-compiler-windows-x86 mkdir ITK-build cd ITK-build/ cmake -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} -G Ninja ../ITK ctest -D Experimental -j6 This will run build the Docker image, which has the CMAKE_TOOLCHAIN_FILE location configured in an environmental variable. The -G Ninja flag tells CMake to use the Ninja Generator. Happy cross-compiling! [Less]

  Introduction An open source development environment is preferred by many developers because of its powerful and effective tools. Additionally, it is desireable to avoid the expense of compiler licenses, proprietary operating systems, and ... [More] hardware when possible. In the age of cloud-based testing and deployment, the ability to work from an open source, Linux stack means services like Travis-CI, etc can be leveraged. In this post, we will walk through the steps to build and test C/C++-based code (ITK) for Windows from Linux or Mac OSX. This requires current ITK Git master, to be released in 4.8.0, and current CMake Git master, to be released in 3.3.0. By the end of the post, we will be able to easily build and test Windows executables from a completely open source stack.   Get the Cross-Compiler The MXE project provides access to the GCC-based MinGW compiler for Windows. It even includes a CMake toolchain file, the configuration file that tells CMake all the information it needs to know about a cross-compiler. First, clone the MXE repository: cd ~/src git clone https://github.com/mxe/mxe.git cd mxe Next, make sure we have all the build dependencies for MXE. A typical Linux development system will already have the dependencies installed. Some dependencies may need to be installed on OSX. On Debian, for example: apt-get install \ autoconf automake autopoint bash bison bzip2 cmake flex gettext \ git g++ gperf intltool libffi-dev libtool-bin libltdl-dev \ libssl-dev libxml-parser-perl make openssl patch perl \ pkg-config python ruby scons sed unzip wget xz-utils After the dependencies are installed, optionally tell MXE what we want to build by default and how we want to build it. This is specified with options in a settings.mk file. We instruct MXE to build a compiler for both 32-bit and 64-bit Windows. To build faster, we can set the number of parallel jobs to the number of cores on our build host. Lastly, MXE can cross-compile a number of packages, but we will just build the cross-compiler itself by default: cat << EOF > settings.mk MXE_TARGETS := x86_64-w64-mingw32.static i686-w64-mingw32.static JOBS := 8 LOCAL_PKG_LIST := gcc .DEFAULT local-pkg-list: local-pkg-list: $(LOCAL_PKG_LIST) EOF Build it!: make   Get the Emulator We will use an emulator to find information about the target system and test our executables. Even though the WINE project's name stands for Wine is Not an Emulator, we can utilize this fantastic, mature tool to emulate Windows. Install it on Debian with: apt-get install wine   Build and Test To download ITK and create a build directory: cd ~/src/ git clone http://itk.org/ITK.git cd ~/bin mkdir ITK-MXE32 cd ITK-MXE32 To build and test ITK for 32-bit Windows: cmake -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_TOOLCHAIN_FILE=~/src/mxe/usr/i686-w64-mingw32.static/share/cmake/mxe-conf.cmake \ -DCMAKE_CROSSCOMPILING_EMULATOR=wine \ ~/src/ITK ctest -j8 -D Experimental The CMAKE_TOOLCHAIN_FILE variable tells CMake about the cross-compiler toolchain we want to use. The CMAKE_CROSSCOMPILING_EMULATOR variables tells CMake what command can be used to emulate the target system. The ctest command will build and test our software and upload the results to CDash so we can visualize the results. CDash provides an overview of build errors, warnings, and which tests are passing and failing. Here we see that most tests pass with a few more failing when built for Windows 64.   What's Next In this post we went through the steps to develop for 32-bit or 64-bit Windows from an x86_64 Linux host. We demonstrated how both build executables and obtain testing results by only specifying two variables in our CMake configuration, CMAKE_TOOLCHAIN_FILE and CMAKE_CROSSCOMPILING_EMULATOR. The reliability of these testing results depend on the quality of the target system emulator, but the presence of testing results on a dashboard is a big step towards better cross-compilation development. In upcoming posts, we'll show how to use the same system to develop ITK-based applications for targets like Javascript for the web browser or NodeJS and Android.     [Less]

  Introduction An open source development environment is preferred by many developers because of its powerful and effective tools. Additionally, it is desireable to avoid the expense of compiler licenses, proprietary operating systems, and ... [More] hardware when possible. In the age of cloud-based testing and deployment, the ability to work from an open source, Linux stack means services like Travis-CI, etc can be leveraged. In this post, we will walk through the steps to build and test C/C++-based code (ITK) for Windows from Linux or Mac OSX. This requires current ITK Git master, to be released in 4.8.0, and current CMake Git master, to be released in 3.3.0. By the end of the post, we will be able to easily build and test Windows executables from a completely open source stack.   Get the Cross-Compiler The MXE project provides access to the GCC-based MinGW compiler for Windows. It even includes a CMake toolchain file, the configuration file that tells CMake all the information it needs to know about a cross-compiler. First, clone the MXE repository: cd ~/src git clone https://github.com/mxe/mxe.git cd mxe Next, make sure we have all the build dependencies for MXE. A typical Linux development system will already have the dependencies installed. Some dependencies may need to be installed on OSX. On Debian, for example: apt-get install \ autoconf automake autopoint bash bison bzip2 cmake flex gettext \ git g++ gperf intltool libffi-dev libtool libltdl-dev \ libssl-dev libxml-parser-perl make openssl patch perl \ pkg-config python ruby scons sed unzip wget xz-utils After the dependencies are installed, optionally tell MXE what we want to build by default and how we want to build it. This is specified with options in a settings.mk file. We instruct MXE to build a compiler for both 32-bit and 64-bit Windows. To build faster, we can set the number of parallel jobs to the number of cores on our build host. Lastly, MXE can cross-compile a number of packages, but we will just build the cross-compiler itself by default: cat << EOF > settings.mk MXE_TARGETS := x86_64-w64-mingw32.static i686-w64-mingw32.static JOBS := 8 LOCAL_PKG_LIST := gcc .DEFAULT local-pkg-list: local-pkg-list: $(LOCAL_PKG_LIST) EOF Build it!: make   Get the Emulator We will use an emulator to find information about the target system and test our executables. Even though the WINE project's name stands for Wine is Not an Emulator, we can utilize this fantastic, mature tool to emulate Windows. Install it on Debian with: apt-get install wine   Build and Test To download ITK and create a build directory: cd ~/src/ git clone http://itk.org/ITK.git cd ~/bin mkdir ITK-MXE32 cd ITK-MXE32 To build and test ITK for 32-bit Windows: cmake -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_TOOLCHAIN_FILE=~/src/mxe/usr/i686-w64-mingw32.static/share/cmake/mxe-conf.cmake \ -DCMAKE_CROSSCOMPILING_EMULATOR=wine \ ~/src/ITK ctest -j8 -D Experimental The CMAKE_TOOLCHAIN_FILE variable tells CMake about the cross-compiler toolchain we want to use. The CMAKE_CROSSCOMPILING_EMULATOR variables tells CMake what command can be used to emulate the target system. The ctest command will build and test our software and upload the results to CDash so we can visualize the results. CDash provides an overview of build errors, warnings, and which tests are passing and failing. Here we see that most tests pass with a few more failing when built for Windows 64.   What's Next In this post we went through the steps to develop for 32-bit or 64-bit Windows from an x86_64 Linux host. We demonstrated how both build executables and obtain testing results by only specifying two variables in our CMake configuration, CMAKE_TOOLCHAIN_FILE and CMAKE_CROSSCOMPILING_EMULATOR. The reliability of these testing results depend on the quality of the target system emulator, but the presence of testing results on a dashboard is a big step towards better cross-compilation development. In upcoming posts, we'll show how to use the same system to develop ITK-based applications for targets like Javascript for the web browser or NodeJS and Android.     [Less]

SIAM's Computational Science and Engineering (CSE) conference was held this year in Salt Lake City. Over one thousand people attended the conference, which featured minisymposia, minitutorials, and keynote addresses. The conference had a lot to ... [More] offer, and Kitware participated in several activities. On the first day of the conference, Bill Hoffman and Andy Bauer attended the career fair and discussed the many perks and benefits of working at Kitware. They also took part in a CASL minisymposia titled "Software Process for a CASL Sustainable Simulation Software Solution." For the minisymposia, Bill presented on CMake, CTest, and CDash, and Andy presented on Computational Model Builder (CMB) and ParaView Catalyst. In addition, Tribits and Hydra-TH were presented. Tribits can be considered an extension of the CMake toolset for the DoE, and Hydra-TH is a powerful CFD package to which Kitware has contributed. Will Schroeder gave a keynote talk titled "Scaling Open Systems for Future Computational Challenges." In his presentation, Will discussed open initiatives in the changing environment surrounding scientific computation and how they relate to HPC, big data, and software architectures. Below is a picture of his talk. The next day, Bob O'Bara presented "OCC-Based Meshing for RGG Applications Using MeshKit" at the minisymposium "Frameworks, Algorithms, and Scalable Technologies for Parallel Unstructured Mesh Workflows."  This was a joint presentation with Kitware, Argonne National Labortory, and the University of Wisconson.  In addition, Bob also participated on Monday's Poster Session with Argonne National Laboratory. To wrap up Kitware's participation in the conference, Andy took part in the Python Visual Analytics for Big Data minitutorial on March 18, showcasing both VTK and ParaView. You can get access to the git repo at https://github.com/JosephCottam/PythonSIAM2015 and to the tutorial at https://www.pathlms.com/siam/courses/1043.   [Less]

SIAM's Computational Science and Engineering (CSE) conference was held this year in Salt Lake City. Over one thousand people attended the conference, which featured minisymposia, minitutorials, and keynote addresses. The conference had a lot to ... [More] offer, and Kitware participated in several activities. On the first day of the conference, Bill Hoffman and Andy Bauer attended the career fair and discussed the many perks and benefits of working at Kitware. They also took part in a CASL minisymposia titled "Software Process for a CASL Sustainable Simulation Software Solution." For the minisymposia, Bill presented on CMake, CTest, and CDash, and Andy presented on Computational Model Builder (CMB) and ParaView Catalyst. In addition, Tribits and Hydra-TH were presented. Tribits can be considered an extension of the CMake toolset for the DoE, and Hydra-TH is a powerful CFD package to which Kitware has contributed. Will Schroeder gave a keynote talk titled "Scaling Open Systems for Future Computational Challenges." In his presentation, Will discussed open initiatives in the changing environment surrounding scientific computation and how they relate to HPC, big data, and software architectures. Below is a picture of his talk. The next day, Bob O'Bara presented "OCC-Based Meshing for RGG Applications Using MeshKit" at the minisymposium "Frameworks, Algorithms, and Scalable Technologies for Parallel Unstructured Mesh Workflows."  This was a joint presentation with Kitware, Argonne National Labortory, and the University of Wisconson.  In addition, Bob also participated on Monday's Poster Session with Argonne National Laboratory. To wrap up Kitware's participation in the conference, Andy took part in the Python Visual Analytics for Big Data minitutorial on March 18, showcasing both VTK and ParaView. You can get access to the git repo at https://github.com/JosephCottam/PythonSIAM2015 and to the tutorial at https://www.pathlms.com/siam/courses/1043.   [Less]