SimGrid
3.16
Versatile Simulation of Distributed Systems
|
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.
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
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).
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.
boost-context
library on your machine, for example with apt-get
.Recompiling an official archive is not much more complex. SimGrid only uses very standard tools:
apt-get install libboost-dev libboost-context-dev
fink install boost1.53.nopython
, or with homebrew: brew install boost
apt-get install default-jdk libgcj16-dev
apt-get install liblua5.3-dev lua5.3
tar xvfz lua-5.3.*.tar.gz
cd lua-5.3*
patch -p1 < /path/to/simgrid/...../tools/lualib.patch
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
You can download the SimGrid-3.16.tar.gz archive from the download page. Then, recompiling the archive should be done in a few lines:
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://scm.gforge.inria.fr/simgrid/simgrid.git simgrid
Note that compile-time options are very different from run-time options.
The default configuration should be fine for most usages, but if you need to change something, there are several ways to do so. First, you can use environment variables. For example, you can change the compilers used by issuing these commands before launching cmake:
export CC=gcc-5.1 export CXX=g++-5.1
Note that other variables are available, such as CFLAGS and CXXFLAGS to add options respectively for the C and C++ compilers.
Another way to do so is to use the -D argument of cmake as follows. Note that the ending dot is mandatory (see Out of Tree Compilation).
cmake -DCC=clang -DCXX=clang++ .
Finally, you can use the ccmake graphical interface to change these settings.
ccmake .
In addition to the classical cmake configuration variables, SimGrid accepts several options, as listed below.
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.
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] .. make
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++ . make
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.
CMAKE_OSX_SYSROOT:PATH=/Applications/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer
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
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.
Once you have the full JDK installed (on Debian/Ubuntu, grab the package default-jdk
for that), things should be as simple as:
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:
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
).
Note that the filename jni.h
was removed from the path.
On a multiarch x86_64 Linux, it should be possible to compile a 32 bit version of SimGrid with something like:
CFLAGS=-m32 \ CXXFLAGS=-m32 \ PKG_CONFIG_LIBDIR=/usr/lib/i386-linux-gnu/pkgconfig/ \ cmake . \ -DCMAKE_SYSTEM_PROCESSOR=i386 \ -DCMAKE_Fortran_COMPILER=/some/path/to/i686-linux-gnu-gfortran \ -DGFORTRAN_EXE=/some/path/to/i686-linux-gnu-gfortran \ -DCMAKE_Fortran_FLAGS=-m32
If needed, implement i686-linux-gnu-gfortran
as a script:
#!/bin/sh exec gfortran -m32 "$@"
In most cases, compiling and installing SimGrid is enough:
make 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
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.