SimGrid  3.19.1
Versatile Simulation of Distributed Systems
Installing Simgrid

SimGrid should work out of the box on Linux, Mac OSX, FreeBSD, and Windows (under windows, only the Java interfaces are available at the moment).

The easiest way to install SimGrid is to go for a binary package. Under Debian or Ubuntu, this is very easy as SimGrid is directly integrated to the official repositories. For other Linux variants, you probably want to go for a source install. Please contact us if you want to contribute the build scripts for your preferred distribution. If you just want to use Java, simply copy the jar file on your disk and you're set.

Pre-compiled Packages

Binaries for Linux

Most of us use a Debian or Ubuntu system, so the packages for these systems are well integrated and up-to-date. To get these packages, simply type:

apt-get install simgrid

Stable Java Package

For the SimGrid Java bindings, grab the jar file from the download page and copy it in your classpath (typically, your source code root directory). This self-contained version even includes the SimGrid native components for the following architectures: Linux (Amd64, x86, Arm), Mac OS X 64 bits, Windows 64 bits, FreeBSD (64 bits).

Nightly built Java Package

For Windows, head to AppVeyor. Click on the artefact link on the right, and grab your file. If the latest build failed, there will be no artefact. Then you will need to first click on "History" on the top and search for the last successful build.

For non-Windows systems (Linux, Mac or FreeBSD), head to Jenkins. In the build history, pick the last green (or at least yellow) build that is not blinking (i.e., not currently under build). In the list, pick a system that is close to yours, and click on the ball in the Debug row. The build artefact will appear on the top of the resulting page.

Binary Java Troubleshooting

  • Your architecture is not supported by this jarfile.
    If your system is in the list of the supported architectures (see above), then this is probably a bug that you should report.
    If your system is actually not supported, you should compile your own jarfile by compiling SimGrid on your machine. If you feel so, contact us so that we add your architecture to the list.
  • Library not found: boost-context.
    You should obviously install the boost-context library on your machine, for example with apt-get.

Source Installs

Getting the Dependencies

Recompiling an official archive is not much more complex. SimGrid only uses very standard tools:

  • C compiler, C++ compiler, make and friends. SimGrid is rather demanding on the compiler. We use the C++11 standard, and older compilers tend to fail on us. It seems that g++ 5.0 or higher is required nowadays (because of boost). SimGrid compiles well with clang too.
  • perl (but you may try to go without it)
  • We use cmake to configure our compilation (download page). You need cmake version 2.8.8 or higher. ccmake provides a nicer graphical interface compared to cmake. Press t in ccmake if you need to see absolutely all configuration options (e.g., if your python installation is not standard).
  • boost:
    • Debian / Ubuntu: apt-get install libboost-dev libboost-context-dev
    • Max OS X: with fink: fink install boost1.53.nopython, or with homebrew: brew install boost
  • Java (if you want to build the Java bindings):
    • Debian / Ubuntu: apt-get install default-jdk libgcj17-dev (any version of libgcj will do it; you can use libgcj16-dev or libgcj18-dev instead, depending on your version of Debian/Ubuntu)
    • Mac OS X or Windows: Grab a full JDK
  • Lua (if you want to build with lua enabled): Your version of Lua must be 5.3. SimGrid won't work with Lua 5.2 nor with 5.1, and probably not with Lua 5.4 either.
    • Debian / Ubuntu: apt-get install liblua5.3-dev lua5.3
    • Windows: choco install lua53
    • From the source: you need to patch the sources to build dynamic libraries
      • Download lua 5.3. SimGrid won't work with lua 5.2 as lua breaks the compatibility.
      • Open the archive: tar xvfz lua-5.3.*.tar.gz
      • Enter the directory: cd lua-5.3*
      • Patch the sources: patch -p1 < /path/to/simgrid/...../tools/lualib.patch
      • Build and install lua: make linux && sudo make install

For platform-specific details, please see Mac OS X Builds, Windows Builds, Build the Java bindings and 32 bits Builds on Multi-arch Linux

Getting the Sources

You can download the SimGrid-3.19.1.tar.gz archive from the download page. Then, recompiling the archive should be done in a few lines:

tar xf SimGrid-3.19.1.tar.gz
cd SimGrid-3.19.1
cmake -DCMAKE_INSTALL_PREFIX=/opt/simgrid .
make install

If you want to stay on the bleeding edge, you should get the latest git version, and recompile it as you would do for an official archive. Depending on the files you change in the source tree, some extra tools may be needed.

git clone git:// simgrid

Build Configuration

This section is about compile-time options, that are very different from run-time options. Compile-time options fall into two categories. SimGrid-specific options define which part of the framework to compile while generic options are provided by cmake itself.

Generic build-time options

These options specify for example the path to various system elements (Python path, compiler to use, etc). In most case, cmake automatically discovers the right value for these ones, but you can set them manually on need. Notable such variables include CC and CXX, defining respectively the C and C++ compiler executables, CFLAGS and CXXFLAGS respectively specifying extra options to pass to the C and C++ compilers, or PYTHON_EXECUTABLE specifying the path to the python executable. The best way to discover the exact name of the option that you need to change is to press 't' in the ccmake graphical interface, as all options are shown (and documented) in the advanced mode.

Once you know their name, there is several ways to change the value of build-time options. You can naturally use the ccmake graphical interface for that, or you can use environment variables, or you can prefer the -D flag of cmake.

For example, you can change the compilers with environment variables by issuing these commands before launching cmake:

export CC=gcc-5.1
export CXX=g++-5.1

The same can be done by passing -D parameters to cmake, as follows. Note that the ending dot is mandatory (see Out of Tree Compilation).

cmake -DCC=clang -DCXX=clang++ .

SimGrid compilation options

Here is the list of SimGrid-specific build-time options.

  • CMAKE_INSTALL_PREFIX (path): Where to install SimGrid (/opt/simgrid, /usr/local, or elsewhere).
  • enable_compile_optimizations (ON/OFF) to request the compiler to produce efficient code. You want to activate it, unless you plan to debug SimGrid itself. Indeed, efficient code may be appear mangled to debuggers.
  • enable_compile_warnings (ON/OFF) to request the compiler to issue error messages whenever the source code is not perfectly clean. If you are a SimGrid developer, you have to activate this option to enforce the code quality. As a regular user, this option will bring you nothing.
  • enable_debug (ON/OFF). Disable this option toto discard all log messages of gravity debug or below at compile time (see Logging support). The resulting code is faster than if you discarding these messages at runtime. However, it obviously becomes impossible to get any debug info from SimGrid if something goes wrong.
  • enable_documentation (ON/OFF) to generate the documentation pages.
  • enable_java (ON/OFF) to enjoy the java bindings of SimGrid.
  • enable_jedule (ON/OFF) to get SimDag producing execution traces that can then be visualized with the Jedule external tool.
  • enable_lua (ON/OFF) to enjoy the lua bindings to the SimGrid internals (this require the liblua5.3-dev and lua-5.3 packages or equivalent).
  • enable_lib_in_jar (ON/OFF) to make sure that the native java bindings are bundled in the jar file.
  • enable_lto (ON/OFF) to enable the Link Time Optimization of the C compiler. This feature really speeds up the produced code, but it is fragile with some versions of GCC.
  • enable_maintainer_mode (ON/OFF) is only needed if you plan to modify very specific parts of SimGrid (e.g., the XML parsers and other related elements). Moreover, this adds an extra dependency on flex and flexml.
  • enable_mallocators (ON/OFF) has to be disabled when tracking memory issues within SimGrid, or our internal memory caching mechanism will fool the debuggers.
  • enable_model-checking (ON/OFF) This execution gear is very usable now, but enabling this option at compile time will hinder simulation speed even when the model-checker is not activated at run time.
  • enable_smpi (ON/OFF) to run MPI code on top of SimGrid.
  • enable_smpi_ISP_testsuite (ON/OFF) to add many extra tests for the model-checker module.
  • enable_smpi_MPICH3_testsuite (ON/OFF) to add many extra tests for the MPI module.

Reset the build configuration

To empty the cmake cache (either when you add a new library or when things go seriously wrong), simply delete your CMakeCache.txt. You may also want to directly edit this file in some circumstances.

Out of Tree Compilation

By default, the files produced during the compilation are placed in the source directory. It is however often better to put them all in a separate directory: cleaning the tree becomes as easy as removing this directory, and you can have several such directories to test several parameter sets or architectures.

For that, go to the directory where the files should be produced, and invoke cmake (or ccmake) with the full path to the SimGrid source as last argument.

mkdir build
cd build
cmake [options] ..

Mac OS X Builds

SimGrid compiles like a charm with clang (version 3.0 or higher) on Mac OS X:

cmake -DCMAKE_C_COMPILER=/path/to/clang -DCMAKE_CXX_COMPILER=/path/to/clang++ .

With the XCode version of clang 4.1, you may get the following error message:

CMake Error: Parse error in cache file build_dir/CMakeCache.txt. Offending entry: /SDKs/MacOSX10.8.sdk

In that case, edit the CMakeCache.txt file directly, so that the CMAKE_OSX_SYSROOT is similar to the following. Don't worry about the warning that the "-pthread" argument is not used, if it appears.


In the El Capitan version of Max OS X, Apple decided that users don't need no /usr/include directory anymore. If you are hit by this pure madness, just run the following command to restore that classical UNIX directory: xcode-select -install

Windows Builds

Building SimGrid on Windows may be something of an adventure: We only manage to do so ourselves with MinGW-64, ActiveState Perl and msys git). Have a look at out configuration scripts in appveyor.yml, but don't expect too much from us: we are really not fluent with Windows. Actually your help is welcome.

The drawback of MinGW-64 is that the produced DLL are not compatible with MS Visual C. clang-cl sounds promising to fix this. If you get something working, please tell us.

Build the Java bindings

Once you have the full JDK installed (on Debian/Ubuntu, grab the package default-jdk for that), things should be as simple as:

cmake -Denable_java=ON .

After the compilation, the file simgrid.jar is produced in the root directory. If you only want to build the jarfile and its dependencies, type make simgrid-java_jar. It will save you the time of building every C examples and other things that you don't need for Java.

Error: jni could not be found. Sometimes, the build system fails to find the JNI headers. In this case, you need to first locate them as follows:

$ locate jni.h

Then, set the JAVA_INCLUDE_PATH environment variable to the right path, and relaunch cmake. If you have several version of jni installed (as above), use the right one (check the java version you use with javac -version).

export JAVA_INCLUDE_PATH=/usr/lib/jvm/java-8-openjdk-amd64/include/
cmake -Denable_java=ON .

Note that the filename jni.h was removed from the path.

32 bits Builds on Multi-arch Linux

On a multiarch x86_64 Linux, it should be possible to compile a 32 bit version of SimGrid with something like:

CFLAGS=-m32 \
PKG_CONFIG_LIBDIR=/usr/lib/i386-linux-gnu/pkgconfig/ \
cmake . \
-DCMAKE_Fortran_COMPILER=/some/path/to/i686-linux-gnu-gfortran \
-DGFORTRAN_EXE=/some/path/to/i686-linux-gnu-gfortran \

If needed, implement i686-linux-gnu-gfortran as a script:

#!/usr/bin/env sh
exec gfortran -m32 "$@"

Existing Compilation Targets

In most cases, compiling and installing SimGrid is enough:

make install # try "sudo make install" if you don't have the permission to write

In addition, several compilation targets are provided in SimGrid. If your system is well configured, the full list of targets is available for completion when using the Tab key. Note that some of the existing targets are not really for public consumption so don't worry if some stuff doesn't work for you.

make simgrid                    Build only the SimGrid library and not any example
make app-masterworker           Build only this example (works for any example)
make clean                      Clean the results of a previous compilation
make install                    Install the project (doc/ bin/ lib/ include/)
make uninstall                  Uninstall the project (doc/ bin/ lib/ include/)
make dist                       Build a distribution archive (tgz)
make distcheck                  Check the dist (make + make dist + tests on the distribution)
make documentation              Create SimGrid documentation

If you want to see what is really happening, try adding VERBOSE=1 to your compilation requests:

make VERBOSE=1

Testing your build

Once everything is built, you may want to test the result. SimGrid comes with an extensive set of regression tests (as described in the insider manual). The tests are run with ctest, that comes with CMake. We run them every commit and the results are on our Jenkins.

ctest                     # Launch all tests
ctest -R msg              # Launch only the tests which name match the string "msg"
ctest -j4                 # Launch all tests in parallel, at most 4 at the same time
ctest --verbose           # Display all details on what's going on
ctest --output-on-failure # Only get verbose for the tests that fail

ctest -R msg- -j5 --output-on-failure # You changed MSG and want to check that you didn't break anything, huh?
                                      # That's fine, I do so all the time myself.