CASToR build on Windows platform

Hi CASToR users and developers,

I recently started working with CASToR and managed to compile it for Ubuntu and Windows. As I am forced to work with Windows, this was my primary targeted platform (Ubuntu VM just for cross-checks).

However, I managed to build a 32bit release with Windows 7 64bit, Visual Studio 2017 (v15.5.5), CMake 3.9.6 and pre-compiled ROOT binaries for Visual Studio 2013 (“”).

During this journey I discovered a couple of errors with CASToR’s (CMake) configuration files which I would to draw your attention to.

This is probably not the right place to submit this, but I could not find any bug tracker or repository to issue cases.

Due to my limited knowledge with CMake I just mention issues here instead of offering true solutions.

My issues:

  1. The default CMakeLists.txt of CASToR provides two forks, one for “win32” and one for unix-based system.

Whereas the unix fork cares for flags as “CASToR_BUILD_GATE_UTILITIES” and checks if “CASToR_ROOT” is set (which is required to read ROOT files), the win32 fork does not check this.

Hence, the build will fail due to missing ROOT libraries.

My solution to this was to copy the parts from the unix part to the corresponding win32 section and it worked. Maybe this is not the way it is supposed to be, please check.

  1. ROOT for Windows can only be built in 32bit mode, as the 64bit version would require a lot of changes to ROOT and the underlying libraries (see

Therefore, whenever a windows platform is detected, the compiler should be force to 32bit mode and the CASToR build as well (see variable “CASToR_64bits”).

At least some prominent error should be displayed if this is easier to implement.

  1. The “FindROOT.cmake” file you provide in “cmake-modules” only works for unix-systems.

Here, the calls to ${ROOT_CONFIG_EXECUTABLE} in the “execute_process” instructions do not work for windows as the “root-config” file cannot be executed.

I adjusted this section by borrowing parts from here:

Again, I do not know if this is the way to go but it works for me.

  1. When using CASToR_ROOT and building in 32bit mode using Visual Studio 2017, this still fails due to some weird error namely:

path_to_my_root_build\include\tvirtualx.h(183): error C2059: syntax error : ‘constant’

I nailed this down to a ROOT bug submitted several years ago:

The solution is to add the line “#include “Windows4Root.h” right before “#include “TCanvas.h” in the file:


I do not know what consequences this has.

  1. One small cosmetic issue (maybe it is a real issue but I did not have an problems with this):

Probably both lines of “add_definitions( /DCASTOR_ROOT )” in the unix-fork of the CMakeLists.txt should be replaced with the hyphenated version (-DCASTOR_ROOT).

At least this is the case for all other flags (-DCASTOR_MPI, -DCASTOR_VERBOSE et.c) in this section. Maybe the compiler will also handle the slash version.

Long story short, the build now works and the results of the executables look promising. Nevertheless, due to the 32bit memory restrictions, this CASToR build is suboptimal.

I now plan on using a 32bit release to convert my GATE geometry data and the corresponding ROOT simulation files into CASToR data files.

In addition, I’m going to build a 64bit release as well and develop my own stuff.

Bottom line: You guys did an amazing job and I really like what v1.2 offers. Keep up the good work!

Yours sincerely,

Moritz Schaar

Hi Moritz Schaar !

Better late than never to thank you for that kind email !

Thanks for spotting all these errors. We will fix them in the next release which we are currently preparing.
I think that nobody never used ROOT with CASToR under Windows ...

I personally use the mingw-w64 cross compiler to compile CASToR for Windows 64 bits from a linux distribution.
We thought about distributing these binaries for Windows users.
Finally, the datafile are now managed using file mapping so reconstructing huge files without much memory won't be a problem anymore.

If I may ask, for what purpose are you using CASToR ? Whatever the reason, thanks for using it !


Hi Simon,

Thanks for the reply. I actually thought my mail got “lost” as I did not receive any notice via the mailing list.

However, I am not very familiar with mingw but maybe this is an option with fewer traps.

If you have an internal release with these binaries and need a novice to test it, feel free to contact me.

I am investigating CASToR for research and educational purpose.

Currently I am elaborating which toolkit could be good starting point for our group to help us build some sort of reconstruction framework.

We mainly focus on GATE simulations for PET and SPECT data and e.g. STIR seems way bloated for us, even though it has interesting things like scatter correction already implemented.

Furthermore, I would like to have students working on smaller projects where they should integrate new parts of their reconstruction in an already existing program and easily see results.

I really like the structure how CASToR is built with modules and different layers of abstraction, even though it takes some time to get familiar with the internal design.

Do you plan to open a (public) repository (git?) or something like this where one can submit issues and bug fixes? At the moment everything seems a bit hidden.

For example I would like to recommend to extend the GATERootToCastor toolkit to allow a more flexible selection of events.

Let’s say I am interested in seeing the direct impact of object scatter to different reconstructions, then I would like to filter out randoms and intercrystal scatter.

Maybe this is a very specialized area of application and of course we can extend this on our own but I think its worthwhile mentioning it here.



Hi Moritz,

Many thanks for all your remarks and suggestions.

To be honest, we just tested once the compilation of CASToR with ROOT on windows (using MSVC 2015 and nmake at the time). As ROOT is only used in CASToR to convert data from GATE, and GATE is only available on Unix systems, we never focused on making the ROOT-related toolkits run on windows, so this is why some features are lacking for windows compilation.

As you suggested, using a public git repository for bug fixes and development would be a great idea, this is definitely something we plan to discuss. As Simon said, we are currently working on a next version which will be available soon. We will then discuss how we can provide more helps to developers and access to the development versions of the code, and come back to you.

Again, many thanks for your work and all your remarks!

Best regards,