\section faq_simgrid I'm new to SimGrid. I have some questions. Where should I start?
You are at the right place... Having a look to these
-<a href="http://graal.ens-lyon.fr/~alegrand/articles/slides_g5k_simul.pdf">slides</a>
-(or to these
+<a href="http://www.loria.fr/~quinson/articles/simgrid-tutorial.pdf">the tutorial slides</a>
+(or to these <a href="http://graal.ens-lyon.fr/~alegrand/articles/slides_g5k_simul.pdf">old slides</a>,
+or to these
<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">"obsolete" slides</a>)
may give you some insights on what SimGrid can help you to do and what
are its limitations. Then you definitely should read the \ref
-MSG_examples. There is also a mailing list: <simgrid-user@lists.gforge.inria.fr>.
+MSG_examples. The \ref GRAS_tut can also help you.
+
+If you are stuck at any point and if this FAQ cannot help you, please drop us a
+mail to the user mailing list: <simgrid-user@lists.gforge.inria.fr>.
\subsection faq_interfaces What is the difference between MSG, SimDag, and GRAS? Do they serve the same purpose?
With SimDag, you express your code as a collection of interdependent
parallel tasks. So, in this model, applications can be seen as a DAG of
tasks. This is the interface of choice for people wanting to port old
-code designed for SimGrid v1 or v2 to the lastest framework.
+code designed for SimGrid v1 or v2 to the framework current version.
With both GRAS and MSG, your application is seen as a set of communicating
processes, exchanging data by the way of messages and performing computation
on their own.
The difference between both is that MSG is somehow easier to use, but GRAS
-is not limitated to the simulator. Once you're done writing your GRAS code,
+is not limited to the simulator. Once you're done writing your GRAS code,
you can run your code both in the simulator or on a real platform. For this,
there is two implementations of the GRAS interface, one for simulation, one
for real execution. So, you just have to relink your code to chose one of
read the \ref GRAS_tut. The first section constitutes an introduction
to the tool and presents the model we use. The second section
constitutes a complete step-by-step tutorial building a distributed
-application from the begining and exemplifying most of the GRAS
+application from the beginning and exemplifying most of the GRAS
features in the process. The last section groups some HOWTOS
highlighting a given feature of the framework in a more concise way.
\endhtmlonly
</center>
-Vizualization with Paje can be seen as a kind of postmortem
+Visualization with Paje can be seen as a kind of postmortem
analysis. However, as soon as you start playing with big simulations,
you'll realize that processing such output is kind of tricky. There is
-so much generic informations that it is hard to find the information
+so much generic information that it is hard to find the information
you are looking for.
-As a matter of fact, loging really depends on simulations (e.g. what
+As a matter of fact, logging really depends on simulations (e.g. what
kind of events is important...). That is why we do not propose a big
dump of your whole simulation (it would slow everything down) but give
you neat tools to structure you logs. Have a look at \ref XBT_log. In
fact, rather than a post-mortem analysis, you may want to do it on the
fly. The process you are running can do whatever you want. Have you
thought about adding a global structure where you directly compute the
-informations that are really important rather than writing everything
+information that are really important rather than writing everything
down and then processing huge files?
\subsection faq_C Argh! Do I really have to code in C?
instructions and still have some troubles, drop an e-mail to
<simgrid-user@lists.gforge.inria.fr>.
-\subsection faq_compiling Compiling SimGrid from an archive
+\subsection faq_compiling Compiling SimGrid from a stable archive
First of all, you need to download the latest version of SimGrid from
<a href="http://gforge.inria.fr/frs/?group_id=12">here</a>.
directory. Change your directory to
<tt>/home/joe/tmp/simgrid-3.0.1</tt> and type
-\verbatim./configure --prefix=$HOME
+\verbatim
+./configure --prefix=$HOME
make
make install
\endverbatim
-If at some point, something fails, check the section "\ref
-faq_trouble_compil". If it does not help, you can report this problem to the
+If at some point, something fails, check the section \ref faq_trouble_compil .
+If it does not help, you can report this problem to the
list but, please, avoid sending a laconic mail like "There is a problem. Is it
okay?". Send the config.log file which is automatically generated by
configure. Try to capture both the standard output and the error output of the
\verbatim export LD_LIBRARY_PATH=$HOME/lib/:$LD_LIBRARY_PATH
\endverbatim
+\subsection faq_compiling_java Java bindings don't get compiled
+
+The configure script detects automatically whether you have the
+softwares needed to use the Java bindings or not. At the end of the
+configure, you can see the configuration picked by the script, which
+should look similar to
+\verbatim Configuration of package simgrid' (version 3.3.4-svn) on
+little64 (=4):
+
+ Compiler: gcc (version: )
+
+ CFlags: -O3 -finline-functions -funroll-loops -fno-strict-aliasing -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wcomment -Wformat -Wwrite-strings -Wno-unused-function -Wno-unused-parameter -Wno-strict-aliasing -Wno-format-nonliteral -Werror -g3
+ CPPFlags:
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Java: no
+
+ Maintainer mode: no
+ Supernovae mode: yes
+\endverbatim
+
+In this example, Java backends won't be compiled.
+
+On Debian-like systems (which includes ubuntu), you need the following
+packages: sun-java6-jdk libgcj10-dev. If you cannot find the
+libgcj10-dev, try another version, like libgcj9-dev (on Ubuntu before
+9.10) or libgcj11-dev (not released yet, but certainly one day).
+Please note that you need to activate the contrib and non-free
+repositories in Debian, and the universe ones in Ubuntu. Java comes at
+this price...
+
+\subsection faq_compiling_snapshoot SimGrid development snapshots
+
+We have very high standards on software quality, and we are reluctant releasing
+a stable release as long as there is still some known bug in the code base. In
+addition, we added quite an extensive test base, making sure that we correctly
+test the most important parts of the tool.
+
+As an unfortunate conclusion, there may be some time between the stable
+releases. If you want to benefit from the most recent features we introduced,
+but don't want to take the risk of an untested version from the SVN, then
+development snapshots are done for you.
+
+These are pre-releases of SimGrid that still fail some tests about features
+that almost nobody use, or on platforms not being in our core target (which is
+Linux, Mac, other Unixes and Windows, from the most important to the less
+one). That means that using this development releases should be safe for most
+users.
+
+These archives can be found on
+<a href="http://www.loria.fr/~quinson/simgrid.html">this web page</a>. Once you
+got the lastest archive, you can compile it just like any archive (see above).
\subsection faq_compiling_svn Compiling SimGrid from the SVN
-The project development takes place in the svn, where all changes are
-commited when they happen. Then every once in a while, we make sure that the
+The project development takes place in the SVN, where all changes are
+committed when they happen. Then every once in a while, we make sure that the
code quality meets our standard and release an archive from the code in the
SVN. We afterward go back to the development in the SVN. So, if you need a
recently added feature and can afford some little problem with the stability
(i.e. anything different from a recent linux distribution) may be
... uncertain. If you need to compile the SVN version on a machine where all these
dependencies are not met, the easiest is to do <tt>make dist</tt> in the SVN
-dir of another machine where all dependencies are met. It will create an
+directory of another machine where all dependencies are met. It will create an
archive you may deploy on other sites just as a regular stable release.
In summary, the following commands will checkout the SVN, regenerate the
them in a specific order with specific arguments. Most of the times, the
makefiles will automatically call the tools for you. When it's not possible
(such as the first time you checkout the SVN), use the ./bootstrap command
-to call them explicitely.
+to call them explicitly.
\subsection faq_setting_MSG Setting up your own MSG code
is not the better source of information. Instead, you should check the GRAS
tutorial in general, and the \ref GRAS_tut_tour_setup in particular.
-\subsection faq_crosscompile Cross-compiling a Windows DLL of SimGrid from linux
+\section faq_cmake CMAKE
-At the moment, we do not distribute Windows pre-compiled version of SimGrid
-because the support for this platform is still experimental. We know that
-some parts of the GRAS environment do not work, and we think that the others
-environments (MSG and SD) have good chances to work, but we didn't test
-ourselves. This section explains how we generate the SimGrid DLL so that you
-can build it for yourself. First of all, you need to have a version more
-recent than 3.1 (ie, a SVN version as time of writting).
+\subsection faq_intro Some generalitty
-In order to cross-compile the package to windows from linux, you need to
-install mingw32 (minimalist gnu win32). On Debian, you can do so by
-installing the packages mingw32 (compiler), mingw32-binutils (linker and
-so), mingw32-runtime.
+\subsubsection faq_intro1 What is Cmake?
-You can use the VPATH support of configure to compile at the same time for
-linux and windows without dupplicating the source nor cleaning the tree
-between each. Just run bootstrap (if you use the SVN) to run the autotools.
-Then, create a linux and a win directories. Then, type:
-\verbatim cd linux; ../configure --srcdir=.. <usual configure flags>; make; cd ..
-cd win; ../configure --srcdir=.. --host=i586-mingw32msvc <flags>; make; cd ..
+CMake is a family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. For more information see official web site <a href="http://www.cmake.org/">here</a>.
+
+\subsubsection faq_intro2 Why cmake?
+
+CMake permits to developers to compil projects on different plateform. Then many tools are embedded like ctest for making test, a link to cdash for vizualise results but also test coverage and bug reports.
+
+\subsubsection faq_intro3 What cmake need?
+
+CMake needs some prerequists like :
+ \li make
+ \li c, c++ and java compiler regards to developers
+ \li ccmake for graphical used of CMake
+ \li cmake <a href="http://www.cmake.org/cmake/resources/software.html">(download page)</a>
+
+\subsubsection faq_intro4 Cmake vs Autotools...
+
+
+
+\subsection faq_cmakeoption Cmake options
+
+\subsubsection faq_cmakeoption1 Liste of options
+
+\verbatim
+"cmake -D[name]=[value] ... ./"
+
+[name] disable_gtnets [value] ON/OFF or TRUE/FALSE or 1/0
+ disable_java ON/OFF or TRUE/FALSE or 1/0
+ disable_lua ON/OFF or TRUE/FALSE or 1/0
+ disable_ruby ON/OFF or TRUE/FALSE or 1/0
+
+ enable_compile_optimizations ON/OFF or TRUE/FALSE or 1/0
+ enable_compile_warnings ON/OFF or TRUE/FALSE or 1/0
+ enable_maintainer_mode ON/OFF or TRUE/FALSE or 1/0
+
+ supernovae ON/OFF or TRUE/FALSE or 1/0
+
+ gtnets_path <path_to_gtnets_directory>
+ prefix <path_to_install_directory>
+ with_context auto/ucontext/pthread/window
\endverbatim
-The trick to VPATH builds is to call configure from another directory,
-passing it an extra --srcdir argument to tell it where all the sources are.
-It will understand you want to use VPATH. Then, the trick to cross-compile
-is simply to add a --host argument specifying the target you want to build
-for. The i586-mingw32msvc string is what you have to pass to use the mingw32
-environment as distributed in Debian.
-After that, you can run all make targets from both directories, and test
-easily that what you change for one arch does not break the other one.
+\subsubsection faq_cmakeoption2 Options explaination
-It is possible that this VPATH build thing breaks from time to time in the
-SVN since it's quite fragile, but it's granted to work in any released
-version. If you experience problems, drop us a mail.
+ \li disable_gtnets : set to true implie that user doesn't want to use gtnets.
-Another possible source of issue is that at the moment, building the
-examples request to use the gras_stub_generator tool, which is a compiled
-program, not a script. In cross-compilation, you need to cross-execute with
-wine for example, which is not really pleasant. We are working on this, but
-in the meanwhile, simply don't build the examples in cross-compilation
-(<tt>cd src</tt> before running make).
-
-Program (cross-)compiled with mingw32 do request an extra DLL at run-time to be
-usable. For example, if you want to test your build with wine, you should do
-the following to put this library where wine looks for DLLs.
-\verbatim
-cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/
-gunzip ~/.wine/c/windows/system/mingwm10.dll.gz
+ \li disable_java : set to true implie that user doesn't want to add java langage into simgrid compilation.
+
+ \li disable_lua : set to true implie that user doesn't want to add lua langage into simgrid compilation.
+
+ \li disable_ruby : set to true implie that user doesn't want to add ruby langage into simgrid compilation.
+
+ \li enable_compile_optimizations : add flags "-O3 -finline-functions -funroll-loops -fno-strict-aliasing"
+
+ \li enable_compile_warnings : add flags "-Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wcomment -Wformat -Wwrite-strings -Wno-unused-function -Wno-unused-parameter -Wno-strict-aliasing -Wno-format-nonliteral -Werror"
+
+ \li enable_maintainer_mode : set to true make doc and remake files with flex flexml.
+\verbatim
+/doc/html
+/src/gras/DataDesc/ddt_parse.yy.c
+/src/surf/simgrid_dtd.c
+/src/xbt/graphxml.c
+/src/simdag/dax_dtd.c
+/include/surf/simgrid_dtd.h
+/include/xbt/graphxml.h
+/src/simdag/dax_dtd.h
\endverbatim
+ \li supernovae : set to true make one file for each lib and compile with those generated files.
+\verbatim
+/src/supernovae_sg.c
+/src/supernovae_gras.c
+/src/supernovae_smpi.c
+\endverbatim
+ \li gtnets_path : Path to gtnets install directory (ex /usr)
-The DLL is builded in src/.libs, and installed in the <i>prefix</i>/bin directory
-when you run make install.
+ \li prefix : Path where are installed lib/ doc/ and include/ directories (ex /usr/local)
-If you want to use it in a native project on windows, you need to use
-simgrid.dll and mingwm10.dll. For each DLL, you need to build .def file
-under linux (listing the defined symbols), and convert it into a .lib file
-under windows (specifying this in a way that windows compilers like). To
-generate the def files, run (under linux):
-\verbatim echo "LIBRARY libsimgrid-0.dll" > simgrid.def
-echo EXPORTS >> simgrid.def
-nm libsimgrid-0.dll | grep ' T _' | sed 's/.* T _//' >> simgrid.def
-nm libsimgrid-0.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> simgrid.def
+ \li with context : specify which context the user wants to use.
-echo "LIBRARY mingwm10.dll" > mingwm10.def
-echo EXPORTS >> mingwm10.def
-nm mingwm10.dll | grep ' T _' | sed 's/.* T _//' >> mingwm10.def
-nm mingwm10.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> mingwm10.def
+\subsubsection faq_cmakeoption3 Initialisation
+
+Those options are initialized the first time you launch \"cmake ./\" whithout specified option.
+
+\verbatim
+with_context auto
+enable_maintainer_mode off
+supernovae off
+disable_java off
+disable_lua off
+enable_compile_warnings off
+enable_compile_optimizations off
+disable_gtnets off
+disable_ruby on
\endverbatim
-To create the import .lib files, use the <tt>lib</tt> windows tool (from
-MSVC) the following way to produce simgrid.lib and mingwm10.lib
-\verbatim lib /def:simgrid.def
-lib /def:mingwm10.def
+\subsubsection faq_cmakeoption4 Option's cache and how to reset?
+
+When options have been set they are keep into a cache file named \"CMakeCache.txt\". So if you want
+reset values you just delete this file located to the project directory.
+
+\subsection faq_cmakecompilation Cmake compilation
+
+\subsubsection faq_cmakecompilation1 With command line.
+
+\verbatim
+cmake -D[name]=[value] ... ./
+make
\endverbatim
-If you happen to use Borland C Builder, the right command line is the
-following (note that you don't need any file.def to get this working).
-\verbatim implib simgrid.lib libsimgrid-0.dll
-implib mingwm10.lib mingwm10.dll
+\subsubsection faq_cmakecompilation2 With ccmake tool.
+
+\verbatim
+"ccmake ./"
\endverbatim
+Then follow instructions.
-Then, set the following parameters in Visual C++ 2005:
-Linker -> Input -> Additional dependencies = simgrid.lib mingwm10.lib
+\subsubsection faq_cmakecompilation3 Resume of command line
-Just in case you wonder how to generate a DLL from libtool in another
-project, we added -no-undefined to any lib*_la_LDFLAGS variables so that
-libtool accepts to generate a dynamic library under windows. Then, to make
-it true, we pass any dependencies (such as -lws2 under windows or -lpthread
-on need) on the linking line. Passing such deps is a good idea anyway so
-that they get noted in the library itself, avoiding the users to know about
-our dependencies and put them manually on their compilation line. Then we
-added the AC_LIBTOOL_WIN32_DLL macro just before AC_PROG_LIBTOOL in the
-configure.ac. It means that we exported any symbols which need to be.
-Nowadays, functions get automatically exported, so we don't need to load our
-header files with tons of __declspec(dllexport) cruft. We only need to do so
-for data, but there is no public data in SimGrid so we are good.
+ \li CMake
+\verbatim
+cmake ./ configure the project
+make build all tagets
+make test test all targets and summarize
+make package make the distrib
+make install-simgrid install the project (doc/ lib/ include/)
+make clean" clean all targets
+\endverbatim
+
+When the project have been succesfully compiling and build you can make tests.
+
+ \li CTest
+\verbatim
+ctest launch only tests
+ctest -D Continuous
+ctest -D Continuous(Start|Update|Configure|Build)
+ctest -D Continuous(Test|Coverage|MemCheck|Submit)
+ctest -D Experimental
+ctest -D Experimental(Start|Update|Configure|Build)
+ctest -D Experimental(Test|Coverage|MemCheck|Submit)
+ctest -D Nightly
+ctest -D Nightly(Start|Update|Configure|Build)
+ctest -D Nightly(Test|Coverage|MemCheck|Submit)
+ctest -D NightlyMemoryCheck
+\endverbatim
+
+\subsubsection faq_cmakecompilation4 Examples for different mode.
+
+\li Mode maintainer
+
+cmake -Denable_maintainer_mode=on ./
+\verbatim GTnetS doesn't works : set -Ddisable_gtnets=on
+with_context auto change to ucontext
+(skaddr)
+(sksize)
+Make : src/simgrid.jar with : /usr/bin/javac
+Make examples/java with : /usr/bin/javac
+
+Configuration of package `simgrid' (revision 7228M) on arch (=4):
+ BUILDNAME : UCONTEXT
+ SITE : Linux_Ubuntu 9.10_x86_64
+
+ Compiler: c++ : /usr/bin/c++
+ version: c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+ c : /usr/bin/gcc
+ version: gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+
+ CFlags: -g3
+ CPPFlags:
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Gtnets: 0
+ path:
+ Compile Java: 1
+ Compile Lua: 1
+ Compile Ruby: 0
+
+ Maintainer mode: on
+ Supernovae mode: off
+
+ Simgrid dependencies: dl -llua5.1
+ Gras dependencies: pthread
+ Ruby dependencies:
+ Smpi dependencies:
+
+ USER_PREFIX: /usr/local
+ INSTALL_PREFIX: /usr/local
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/navarrop/Bureau/simgrid-trunk
+\endverbatim
+
+\li Mode supernovae
+
+cmake -Dsupernovae=on ./
+\verbatim GTnetS doesn't works : set -Ddisable_gtnets=on
+with_context auto change to ucontext
+(skaddr)
+(sksize)
+Make : src/simgrid.jar with : /usr/bin/javac
+Make examples/java with : /usr/bin/javac
+
+Configuration of package `simgrid' (revision 7228M) on arch (=4):
+ BUILDNAME : SUPERNOVAE
+ SITE : Linux_Ubuntu 9.10_x86_64
+
+ Compiler: c++ : /usr/bin/c++
+ version: c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+ c : /usr/bin/gcc
+ version: gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+
+ CFlags: -O3 -finline-functions -funroll-loops -fno-strict-aliasing -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wcomment -Wformat -Wwrite-strings -Wno-unused-function -Wno-unused-parameter -Wno-strict-aliasing -Wno-format-nonliteral -Werror -g3
+ CPPFlags:
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Gtnets: 0
+ path:
+ Compile Java: 1
+ Compile Lua: 1
+ Compile Ruby: 0
+
+ Maintainer mode: off
+ Supernovae mode: on
+
+ Simgrid dependencies: dl -llua5.1
+ Gras dependencies: pthread
+ Ruby dependencies:
+ Smpi dependencies:
+
+ USER_PREFIX: /usr/local
+ INSTALL_PREFIX: /usr/local
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/navarrop/Bureau/simgrid-trunk
+\endverbatim
+
+\li Mode GTnetS
+
+cmake -Dgtnets_path=/home/navarrop/Bureau/usr/ ./
+\verbatim with_context auto change to ucontext
+(skaddr)
+(sksize)
+Make : src/simgrid.jar with : /usr/bin/javac
+Make examples/java with : /usr/bin/javac
+
+Configuration of package `simgrid' (revision 7228M) on arch (=4):
+ BUILDNAME : GTNETS
+ SITE : Linux_Ubuntu 9.10_x86_64
+
+ Compiler: c++ : /usr/bin/c++
+ version: c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+ c : /usr/bin/gcc
+ version: gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+
+ CFlags: -L/home/navarrop/Bureau/usr/lib -I/home/navarrop/Bureau/usr/include/gtnets -g3
+ CPPFlags: -L/home/navarrop/Bureau/usr/lib -I/home/navarrop/Bureau/usr/include/gtnets
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Gtnets: 1
+ path: /home/navarrop/Bureau/usr
+ Compile Java: 1
+ Compile Lua: 1
+ Compile Ruby: 0
+
+ Maintainer mode: off
+ Supernovae mode: off
+
+ Simgrid dependencies: dl -llua5.1 -lgtnets
+ Gras dependencies: pthread
+ Ruby dependencies:
+ Smpi dependencies:
+
+ USER_PREFIX: /usr/local
+ INSTALL_PREFIX: /usr/local
+
+INFO -->> Take care to have export LD_LIBRARY_PATH before run make command for make examples with gtnets
+copy and paste : export LD_LIBRARY_PATH=/home/navarrop/Bureau/usr/lib/:$LD_LIBRARY_PATH
+
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/navarrop/Bureau/simgrid-trunk
+\endverbatim
+
+\subsection faq_cmakeinstall How to install with cmake?
+
+\subsubsection faq_cmakeinstall1 From svn.
+
+\verbatim
+cmake -Denable_maintainer_mode=on -Dprefix=/home/navarrop/Bureau/install_simgrid ./
+make
+make install-simgrid
+\endverbatim
+
+\subsubsection faq_cmakeinstall2 From a distrib
+
+\verbatim
+cmake -Dprefix=/home/navarrop/Bureau/install_simgrid ./
+make
+make install-simgrid
+\endverbatim
+
+\subsection faq_screenshot Screenshot
+
+\verbatim
+navarrop@caraja:~$ cd Bureau/simgrid-trunk/
+navarrop@caraja:~/Bureau/simgrid-trunk$ cmake ./
+
+GTnetS doesn't works : set -Ddisable_gtnets=on <-|some warnings are printed
+with_context auto change to ucontext <-|
+(skaddr) <--info (needed)
+(sksize) <--info (needed)
+Make : src/simgrid.jar with : /usr/bin/javac <--info (if java)
+Make examples/java with : /usr/bin/javac <--info (if java)
+
+Configuration of package `simgrid' (revision 7209M) on arch (=4):
+ BUILDNAME : UCONTEXT <-- name of the compilation regarding to cdash
+ SITE : Linux_Ubuntu 9.10_x86_64 <-- distribution of the local machine regarding to cdash
+
+ Compiler: c++ : /usr/bin/c++
+ version: c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+ c : /usr/bin/gcc
+ version: gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+
+ CFlags: -g3
+ CPPFlags:
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Gtnets: 0
+ path:
+ Compile Java: 1
+ Compile Lua: 1
+ Compile Ruby: 0
+
+ Maintainer mode: OFF
+ Supernovae mode: OFF
+
+ Simgrid dependencies: -ldl -llua5.1
+ Gras dependencies: pthread
+ Ruby dependencies:
+ Smpi dependencies:
+
+ USER_PREFIX: /usr/local
+ INSTALL_PREFIX: /usr/local
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/navarrop/Bureau/simgrid-trunk
+\endverbatim
+Here all options are checked and printed. If it doesn't match with your configuration
+it is probably due to a wrong configuration.
+
+\subsection faq_cmakehowto How to modified sources files for developers
+
+\subsubsection faq_cmakehowto1 Add an executable or examples.
+
+If you want make an executable you have to create a CMakeList.txt to the src directory.
+You must specified where to create the executable, source list, dependencies and the name of the binary.
+
+\verbatim
+cmake_minimum_required(VERSION 2.6)
+
+set(EXECUTABLE_OUTPUT_PATH "./")
+set(LIBRARY_OUTPUT_PATH "${PROJECT_DIRECTORY}/lib")
+
+add_executable(get_sender get_sender.c) #add_executable(<name_of_target> <src list>)
+
+### Add definitions for compile
+target_link_libraries(get_sender simgrid m pthread -fprofile-arcs) #target_link_libraries(<name_of_targe> <dependencies>)
+\endverbatim
+
+Then you have to modified <project/directory>/buildtools/Cmake/src/CMakeMakeExeLib.txt and add
+this line :
+\verbatim
+add_subdirectory(${PROJECT_DIRECTORY}/<path_where_is_CMakeList.txt>)
+\endverbatim
+
+\subsubsection faq_cmakehowto2 Delete/add sources to lib.
+
+If you want modified, add or delete source files from a library you have to edit <project/directory>/buildtools/Cmake/src/CMakeDefinePackages.txt
+
+\verbatim
+set(JMSG_JAVA_SRC
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/MsgException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/JniException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/NativeException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/HostNotFoundException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/ProcessNotFoundException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Msg.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Process.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Host.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Task.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/MsgNative.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/ApplicationHandler.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Sem.java
+)
+\endverbatim
+
+\subsubsection faq_cmakehowto3 Add test
+
+If you want modified, add or delete tests you have to edit <project/directory>/buildtools/Cmake/src/CMakeTest.txt
+with this function : ADD_TEST(<name> <bin> <ARGS>)
+
+\verbatim
+add_test(test-simdag-1 ${PROJECT_DIRECTORY}/testsuite/simdag/sd_test --cfg=path:${PROJECT_DIRECTORY}/testsuite/simdag small_platform_variable.xml)
+\endverbatim
+
+\subsection faq_cmakeExplain Explaination of sources files for cmake
+
+\li CMakeLists.txt
+
+Those files are the "main parts". One located at the project directory call all the cmake sources files. The others
+are little projects called by the first for make examples.
+
+\li CMakeCompleteInFiles.txt
+
+Complete all .in files and define Variables for h files
+
+\li CMakeDocs.txt
+
+This file make the html documentation.
+
+\li CMakeMakeExeLib.txt
+
+Here are callled all "CMakeLists.txt" for make executables and libraries.
+
+\li CMakePrintArgs.txt
+
+This file is called at the end of the build for summarize environment variables.
+
+\li CMakeDefinePackages.txt
+
+Here is defined sources packages for compiling libs.
+
+\li CMakeFlags.txt
+
+Defined flags which are used for compiling sources.
+
+\li CMakeSupernovae.txt
+
+Here are made files for the supernovae mode.
+
+\li CMakeDistrib.txt
+
+Here is defined packages for install simgrid and make a distribution.
+
+\li CMakeFLEXml.txt
+
+Part for generated sources from flex and flexml.
+
+\li CMakeOption.txt
+
+Here are defined options and initialized values.
+
+\li CMakeTest.txt
+
+All tests are listed.
+
+\li CTestConfig.cmake
+
+Properties which link tests with dashboard.
+
+\subsection faq_cmakeList List of files added for cmake
+
+Here is a list of files involved into cmake build (relative to project directory path) :
+\verbatim
+
+Cmake sources:
+ ./buildtools/Cmake/src/CMakeCompleteInFiles.txt
+ ./buildtools/Cmake/src/CMakeDocs.txt
+ ./buildtools/Cmake/src/CMakeMakeExeLib.txt
+ ./buildtools/Cmake/src/CMakePrintArgs.txt
+ ./buildtools/Cmake/src/CMakeDefinePackages.txt
+ ./buildtools/Cmake/src/CMakeFlags.txt
+ ./buildtools/Cmake/src/CMakeSupernovae.txt
+ ./buildtools/Cmake/src/CMakeDistrib.txt
+ ./buildtools/Cmake/src/CMakeFLEXml.txt
+ ./buildtools/Cmake/src/CMakeOption.txt
+ ./buildtools/Cmake/src/CMakeTest.txt
+ ./buildtools/Cmake/src/CTestConfig.cmake
+
+Test files for define properties :
+ ./buildtools/Cmake/prog_test/prog_GRAS_ARCH.c
+ ./buildtools/Cmake/prog_test/prog_max_size.c
+ ./buildtools/Cmake/prog_test/prog_sem_init.c
+ ./buildtools/Cmake/prog_test/prog_stackgrowth.c
+ ./buildtools/Cmake/prog_test/prog_vsnprintf.c
+ ./buildtools/Cmake/prog_test/prog_AC_CHECK_MCSC.c
+ ./buildtools/Cmake/prog_test/prog_GRAS_CHECK_STRUCT_COMPACTION.c
+ ./buildtools/Cmake/prog_test/prog_mutex_timedlock.c
+ ./buildtools/Cmake/prog_test/prog_sem_timedwait.c
+ ./buildtools/Cmake/prog_test/prog_stacksetup.c
+ ./buildtools/Cmake/prog_test/prog_getline.c
+ ./buildtools/Cmake/prog_test/prog_gtnets.cpp
+ ./buildtools/Cmake/prog_test/prog_printf_null.c
+ ./buildtools/Cmake/prog_test/prog_snprintf.c
+ ./buildtools/Cmake/prog_test/prog_va_copy.c
+
+CMakeLists for each binaries or examples:
+ ./CMakeLists.txt
+ ./teshsuite/gras/empty_main/CMakeLists.txt
+ ./teshsuite/gras/small_sleep/CMakeLists.txt
+ ./teshsuite/gras/datadesc/CMakeLists.txt
+ ./teshsuite/gras/msg_handle/CMakeLists.txt
+ ./teshsuite/simdag/CMakeLists.txt
+ ./teshsuite/simdag/partask/CMakeLists.txt
+ ./teshsuite/simdag/platforms/CMakeLists.txt
+ ./teshsuite/simdag/network/CMakeLists.txt
+ ./teshsuite/simdag/network/mxn/CMakeLists.txt
+ ./teshsuite/simdag/network/p2p/CMakeLists.txt
+ ./teshsuite/xbt/CMakeLists.txt
+ ./teshsuite/msg/CMakeLists.txt
+ ./tools/gras/CMakeLists.txt
+ ./tools/tesh/CMakeLists.txt
+ ./testsuite/simdag/CMakeLists.txt
+ ./testsuite/xbt/CMakeLists.txt
+ ./testsuite/surf/CMakeLists.txt
+ ./examples/gras/properties/CMakeLists.txt
+ ./examples/gras/ping/CMakeLists.txt
+ ./examples/gras/pmm/CMakeLists.txt
+ ./examples/gras/mmrpc/CMakeLists.txt
+ ./examples/gras/synchro/CMakeLists.txt
+ ./examples/gras/timer/CMakeLists.txt
+ ./examples/gras/mutual_exclusion/simple_token/CMakeLists.txt
+ ./examples/gras/spawn/CMakeLists.txt
+ ./examples/gras/chrono/CMakeLists.txt
+ ./examples/gras/rpc/CMakeLists.txt
+ ./examples/gras/all2all/CMakeLists.txt
+ ./examples/simdag/properties/CMakeLists.txt
+ ./examples/simdag/CMakeLists.txt
+ ./examples/simdag/metaxml/CMakeLists.txt
+ ./examples/simdag/dax/CMakeLists.txt
+ ./examples/smpi/CMakeLists.txt
+ ./examples/amok/bandwidth/CMakeLists.txt
+ ./examples/amok/saturate/CMakeLists.txt
+ ./examples/msg/priority/CMakeLists.txt
+ ./examples/msg/properties/CMakeLists.txt
+ ./examples/msg/migration/CMakeLists.txt
+ ./examples/msg/gtnets/CMakeLists.txt
+ ./examples/msg/parallel_task/CMakeLists.txt
+ ./examples/msg/trace/CMakeLists.txt
+ ./examples/msg/suspend/CMakeLists.txt
+ ./examples/msg/masterslave/CMakeLists.txt
+ ./examples/msg/actions/CMakeLists.txt
+ ./examples/msg/sendrecv/CMakeLists.txt
+\endverbatim
\section faq_howto Feature related questions
Here is the deal. The whole SimGrid project (MSG, SURF, GRAS, ...) is
meant to be kept as simple and generic as possible. We cannot add
-functions for everybody's need when these functions can easily be
+functions for everybody's needs when these functions can easily be
built from the ones already in the API. Most of the time, it is
possible and when it was not possible we always have upgraded the API
accordingly. When somebody asks us a question like "How to do that?
We know. We should add some more examples, but not really some more
complex ones... We should add some examples that illustrate some other
-functionalities (like how to simply encode asynchronous
+functionalists (like how to simply encode asynchronous
communications, RPC, process migrations, thread synchronization, ...)
and we will do it when we will have a little bit more time. We have
tried to document the examples so that they are understandable. Tell
MSG_task_get_remaining_computation(), MSG_task_get_data_size(),
and MSG_task_get_data().
-You could use a dictionnary (#xbt_dict_t) of dynars (#xbt_dynar_t). If
+You could use a dictionary (#xbt_dict_t) of dynars (#xbt_dynar_t). If
you still don't see how to do it, please come back to us...
\subsubsection faq_MIA_asynchronous I want to do asynchronous communications in MSG
\subsubsection faq_SG_comm Implementing communication delays between tasks.
-A classic question of SimDag newcommers is about how to express a
+A classic question of SimDag newcomers is about how to express a
communication delay between tasks. The thing is that in SimDag, both
computation and communication are seen as tasks. So, if you want to
model a data dependency between two DAG tasks t1 and t2, you have to
result in *fat* simulation hindering debugging.
- It was really boring to write 25,000 entries in the deployment
file, so I wrote a little script
- <tt>examples/gras/tokenS/make_deployment.pl</tt>, which you may
+ <tt>examples/gras/mutual_exclusion/simple_token/make_deployment.pl</tt>, which you may
want to adapt to your case. You could also think about hijacking
the SURFXML parser (have look at \ref faq_flexml_bypassing).
- The deployment file became quite big, so I had to do what is in
user don't get into trouble about this. You want to tune this
size to increse the number of processes. This is the
<tt>STACK_SIZE</tt> define in
- <tt>src/xbt/context_private.h</tt>, which is 128kb by default.
+ <tt>src/xbt/xbt_context_sysv.c</tt>, which is 128kb by default.
Reduce this as much as you can, but be warned that if this value
is too low, you'll get a segfault. The token ring example, which
- is quite simple, runs with 40kb stacks.
+ is quite simple, runs with 40kb stacks.
+ - You may tweak the logs to reduce the stack size further. When
+ logging something, we try to build the string to display in a
+ char array on the stack. The size of this array is constant (and
+ equal to XBT_LOG_BUFF_SIZE, defined in include/xbt/log/h). If the
+ string is too large to fit this buffer, we move to a dynamically
+ sized buffer. In which case, we have to traverse one time the log
+ event arguments to compute the size we need for the buffer,
+ malloc it, and traverse the argument list again to do the actual
+ job.\n
+ The idea here is to move XBT_LOG_BUFF_SIZE to 1, forcing the logs
+ to use a dynamic array each time. This allows us to lower further
+ the stack size at the price of some performance loss...\n
+ This allowed me to run the reduce the stack size to ... 4k. Ie,
+ on my 1Gb laptop, I can run more than 250,000 processes!
\subsubsection faq_MIA_batch_scheduler Is there a native support for batch schedulers in SimGrid?
generic way is thus very hard). However some people have implemented
their own batch schedulers. Vincent Garonne wrote one during his PhD
and put his code in the contrib directory of our SVN so that other can
-keep working on it. You may find inspinring ideas in it.
+keep working on it. You may find inspiring ideas in it.
\subsubsection faq_MIA_checkpointing I need a checkpointing thing
There is several little examples in the archive, in the examples/msg
directory. From time to time, we are asked for other files, but we
-don't have any at hand right now.
+don't have much at hand right now.
-We do have a description of the Grid'5000 platform, but because of
-some flaws in the current formalism, this file is actually 500Mb,
-which is ways too big to be used in the parser. We have an internship
-currently working on xml syntax improvements which will allow to
-reduce the size of this file and release it.
-
-Once it's done, we plan to model manually other existing platforms the
-same way we did for G5K and also release those files in some sort of
-SimGrid platform catalog project.
+You should refer to the Platform Description Archive
+(http://pda.gforge.inria.fr) project to see the other platform file we
+have available, as well as the Simulacrum simulator, meant to generate
+SimGrid platforms using all classical generation algorithms.
\subsubsection faq_platform_alnem How can I automatically map an existing platform?
</route>
\endverbatim
-Althrough it is perfectly valid, it does not mean that data traveling
+Although it is perfectly valid, it does not mean that data traveling
from A to C can either go directly (using link 3) or through B (using
links 1 and 2). It simply means that the routing on the graph is not
trivial, and that data do not following the shortest path in number of
the provided ones.
You are also free to declare platform where the routing is not
-symetric. For example, add the following to the previous file:
+symmetric. For example, add the following to the previous file:
\verbatim
<route src="C" dst="A">
\subsubsection faq_flexml_bypassing Bypassing the XML parser with your own C functions
-So you want to bypass the XML files parser, uh? Maybe doin some parameter
+So you want to bypass the XML files parser, uh? Maybe doing some parameter
sweep experiments on your simulations or so? This is possible, and
it's not even really difficult (well. Such a brutal idea could be
harder to implement). Here is how it goes.
functions. An example of this trick is distributed in the file
examples/msg/masterslave/masterslave_bypass.c
+\subsection faq_simgrid_configuration Changing SimGrid's behavior
+
+A number of options can be given at runtime to change the default
+SimGrid behavior. In particular, you can change the default cpu and
+network models...
+
+\subsubsection faq_simgrid_configuration_gtnets Using GTNetS
+
+It is possible to use a packet-level network simulator
+instead of the default flow-based simulation. You may want to use such
+an approach if you have doubts about the validity of the default model
+or if you want to perform some validation experiments. At the moment,
+we support the GTNetS simulator (it is still rather experimental
+though, so leave us a message if you play with it).
+
+
+<i>
+To enable GTNetS model inside SimGrid it is needed to patch the GTNetS simulator source code
+and build/install it from scratch
+</i>
+
+ - <b>Download and enter the recent downloaded GTNetS directory</b>
+
+ \verbatim
+ svn checkout svn://scm.gforge.inria.fr/svn/simgrid/contrib/trunk/GTNetS/
+ cd GTNetS
+ \endverbatim
+
+
+ - <b>Use the following commands to unzip and patch GTNetS package to work within SimGrid.</b>
+
+ \verbatim
+ unzip gtnets-current.zip
+ tar zxvf gtnets-current-patch.tgz
+ cd gtnets-current
+ cat ../00*.patch | patch -p1
+ \endverbatim
+
+ - <b>OPTIONALLY</b> you can use a patch for itanium 64bit processor family.
+
+ \verbatim
+ cat ../AMD64-FATAL-Removed-DUL_SIZE_DIFF-Added-fPIC-compillin.patch | patch -p1
+ \endverbatim
+
+ - <b>Compile GTNetS</b>
+
+ Due to portability issues it is possible that GTNetS does not compile in your architecture. The patches furnished in SimGrid SVN repository are intended for use in Linux architecture only. Unfortunately, we do not have the time, the money, neither the manpower to guarantee GTNetS portability. We advice you to use one of GTNetS communication channel to get more help in compiling GTNetS.
+
+
+ \verbatim
+ ln -sf Makefile.linux Makefile
+ make depend
+ make debug
+ \endverbatim
+
+
+ - <b>NOTE</b> A lot of warnings are expected but the application should compile
+ just fine. If the makefile insists in compiling some QT libraries
+ please try a make clean before asking for help.
+
+
+ - <b>To compile optimized version</b>
+
+ \verbatim
+ make opt
+ \endverbatim
+
+
+ - <b>Installing GTNetS</b>
+
+ It is important to put the full path of your libgtsim-xxxx.so file when creating the symbolic link. Replace < userhome > by some path you have write access to.
+
+ \verbatim
+ ln -sf /<absolute_path>/gtnets_current/libgtsim-debug.so /<userhome>/usr/lib/libgtnets.so
+ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/<userhome>/usr/lib/libgtnets.so
+ mkdir /<userhome>/usr/include/gtnets
+ cp -fr SRC/*.h /<userhome>/usr/include/gtnets
+ \endverbatim
+
+
+ - <b>Enable GTNetS support in SimGrid</b>
+
+ \verbatim
+ ./configure --with-gtnets=/<userhome>/usr
+ \endverbatim
+
+ - <b>Once you have followed all the instructions for compiling and
+ installing successfully you can activate this feature at
+ runntime with the following options:</b>
+
+ \verbatim
+ cd simgrid/example/msg/
+ make
+ make check
+ \endverbatim
+
+
+ - <b>Or try the GTNetS model dogbone example with</b>
+
+ \verbatim
+ gtnets/gtnets gtnets/onelink-p.xml gtnets/onelink-d.xml --cfg=network_model:GTNets
+ \endverbatim
+
+
+ A long version of this <a href="http://gforge.inria.fr/docman/view.php/12/6283/GTNetS HowTo.html">HowTo</a> it is available
+
+
+ More about GTNetS simulator at <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/index.html">GTNetS Website</a>
+
+
+ - <b>DISCLAIMER</b>
+ The patches provided by us worked successfully with GTNetS found
+ <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/software/gtnets-current.zip">here</a>,
+ dated from 12th June 2008. Due to the discontinuing development of
+ GTNetS it is impossible to precise a version number. We STRONGLY recommend you
+ to download and install the GTNetS version found in SimGrid repository as explained above.
+
+
+
+
+\subsubsection faq_simgrid_configuration_alternate_network Using alternative flow models
+
+The default simgrid network model uses a max-min based approach as
+explained in the research report
+<a href="ftp://ftp.ens-lyon.fr/pub/LIP/Rapports/RR/RR2002/RR2002-40.ps.gz">A Network Model for Simulation of Grid Application</a>.
+Other models have been proposed and implemented since then (see for example
+<a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>)
+and can be activated at runtime. For example:
+\verbatim
+./mycode platform.xml deployment.xml --cfg=workstation_model:compound --cfg=network_model:LV08 -cfg=cpu_model:Cas01
+\endverbatim
+
+Possible models for the network are currently "Constant", "CM02",
+"LegrandVelho", "GTNets", Reno", "Reno2", "Vegas". Others will
+probably be added in the future and many of the previous ones are
+experimental and are likely to disappear without notice...
+
\section faq_troubleshooting Troubleshooting
\subsection faq_trouble_lib_compil SimGrid compilation and installation problems
\subsubsection faq_trouble_lib_config ./configure fails!
-We now only one reason for the configure to fail:
+We know only one reason for the configure to fail:
- - <b>You are using a borken build environment</b>\n
+ - <b>You are using a broken build environment</b>\n
If symptom is that configure complains about gcc not being able to build
executables, you are probably missing the libc6-dev package. Damn Ubuntu.
There is several reasons which may cause the make check to fail on your
machine:
- - <b>You are using a borken libc (probably concerning the contextes)</b>.\n
+ - <b>You are using a broken libc (probably concerning the contextes)</b>.\n
The symptom is that the "make check" fails within the examples/msg directory.\n
By default, SimGrid uses something called ucontexts. This is part of the
libc, but it's quite undertested. For example, some (old) versions of the
glibc on alpha do not implement these functions, but provide the stubs
- (which return ENOSYS: not implemented). It may fool our detection mecanism
+ (which return ENOSYS: not implemented). It may fool our detection mechanism
and leads to segfaults. There is not much we can do to fix the bug.
A workaround is to compile with --with-context=pthread to avoid
- ucontext completely. You'll be a bit more limitated in the number
- of simulated processes you can start concurently, but 5000
+ ucontext completely. You'll be a bit more limited in the number
+ of simulated processes you can start concurrently, but 5000
processes is still enough for most purposes, isn't it?\n
This limitation is the reason why we insist on using this piece of ...
software even if it's so troublesome.\n
for all the details, but you simply forgot to call one of
XBT_LOG_NEW_DEFAULT_CATEGORY() or XBT_LOG_NEW_DEFAULT_SUBCATEGORY().
-\subsubsection faq_trouble_pthreadstatic "gcc: undefinded reference to pthread_key_create"
+\subsubsection faq_trouble_pthreadstatic "gcc: undefined reference to pthread_key_create"
This indicates that one of the library SimGrid depends on (libpthread
here) was missing on the linking command line. Dependencies of
Actually, the message comes directly from FleXML, the technology on top of
which the parser is built. FleXML has the bad idea of fetching the whole
document in memory before parsing it. And moreover, the memory buffer size
-must be determinded at compilation time.
+must be determined at compilation time.
We use a value which seems big enough for our need without bloating the
simulators footprints. But of course your mileage may vary. In this case,
Flex is recent enough (>= 2.5.31). If not the compilation process should
warn you.
-A while ago, we worked on FleXML to reduce a bit its memory consumtion, but
+A while ago, we worked on FleXML to reduce a bit its memory consumption, but
these issues remain. There is two things we should do:
- use a dynamic buffer instead of a static one so that the only limit
and it breaks the hack we devised to bypass the parser, as explained in
\ref faq_flexml_bypassing. Indeed, this is not a classical usage of the
parser, and Will didn't imagine that we may have used (and even documented)
-such a crude usage of FleXML. So, we now have to repare the bypassing
-functionnality to use the lastest FleXML version and fix the memory usage in
+such a crude usage of FleXML. So, we now have to repair the bypassing
+functionality to use the lastest FleXML version and fix the memory usage in
SimGrid.
\subsubsection faq_trouble_gras_transport GRAS spits networking error messages
Gras, on real platforms, naturally use regular sockets to communicate. They
-are deeply hiden in the gras abstraction, but when things go wrong, you may
+are deeply hidden in the gras abstraction, but when things go wrong, you may
get some weird error messages. Here are some example, with the probable
reason:
- <b>Socket closed by remote side</b>: if the remote process is not
supposed to close the socket at this point, it may be dead.
- - <b>Connection reset by peer</b>: I found this on internet about this
+ - <b>Connection reset by peer</b>: I found this on Internet about this
error. I think it's what's happening here, too:\n
<i>This basically means that a network error occurred while the client was
receiving data from the server. But what is really happening is that the
\subsubsection faq_trouble_errors_big_fat_warning I'm told that my XML files are too old.
-We have decided to change the units in SimGrid. Now we use Bytes, Flops and
-seconds instead of MBytes, MFlops and seconds... Units should be updated
-accordingly and the version of platform_description should be set to a
-valuer greater than 1:
+The format of the XML platform description files is sometimes
+improved. For example, we decided to change the units used in SimGrid
+from MBytes, MFlops and seconds to Bytes, Flops and seconds to ease
+people exchanging small messages. We also reworked the route
+descriptions to allow more compact descriptions.
+
+That is why the XML files are versionned using the 'version' attribute
+of the root tag. Currently, it should read:
\verbatim
- <platform_description version="1">
+ <platform version="2">
\endverbatim
-You should try to use the surfxml_update.pl script that can be found
-<a href="https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/contrib/trunk/platform_generation/?rev=4721&root=simgrid"">here</a>.
-\subsection faq_trouble_valgrind Valgrind-related issues
+If your files are too old, you can use the simgrid_update_xml.pl
+script which can be found in the tools directory of the archive.
+
+\subsection faq_trouble_valgrind Valgrind-related and other debugger issues
If you don't, you really should use valgrind to debug your code, it's
almost magic.
-\subsubsection faq_trouble_vg_context Stack switching problems and truncated backtraces
-
-With the default version of simgrid, valgrind will probably spit tons
-of warnings about stack switching like the following, and produce
-truncated bactraces where only one call appears instead of the whole
-stack.
-
-\verbatim
-==14908== Warning: client switching stacks? SP change: 0xBEA2A48C --> 0x476F350
-==14908== to suppress, use: --max-stackframe=1171541700 or greater
-==14908== Warning: client switching stacks? SP change: 0x476E1E4 --> 0xBEA2A48C
-==14908== to suppress, use: --max-stackframe=1171537240 or greater
-==14908== Warning: client switching stacks? SP change: 0xBEA2A48C --> 0x4792420
-==14908== to suppress, use: --max-stackframe=1171685268 or greater
-==14908== further instances of this message will not be shown.
-\endverbatim
-
-This is because valgrind don't like too much the UNIX98 contextes we
-use by default in simgrid for efficiency reasons. Simply add the
---with-pthread flag to your configure when debugging your code. You
-may also find --disable-compiler-optimization usefull if valgrind or
-gdb get fooled by the optimization done by the compiler. But you
-should remove these flages when everything works before going in
-production (before launching your 1252135 experiments), or everything
-will run only one third of the true SimGrid potential.
-
\subsubsection faq_trouble_vg_longjmp longjmp madness in valgrind
This is when valgrind starts complaining about longjmp things, just like:
==21434== at 0x420DC3A: __longjmp (__longjmp.S:48)
\endverbatim
-or even when it reports scary things like:
-
-\verbatim ==24023== Warning: client switching stacks? SP change: 0xBE3FF618 --> 0xBE7FF710
-x86->IR: unhandled instruction bytes: 0xF4 0xC7 0x83 0xD0
-==24023== to suppress, use: --max-stackframe=4194552 or greater
-==24023== Your program just tried to execute an instruction that Valgrind
-==24023== did not recognise. There are two possible reasons for this.
-==24023== 1. Your program has a bug and erroneously jumped to a non-code
-==24023== location. If you are running Memcheck and you just saw a
-==24023== warning about a bad jump, it's probably your program's fault.
-==24023== 2. The instruction is legitimate but Valgrind doesn't handle it,
-==24023== i.e. it's Valgrind's fault. If you think this is the case or
-==24023== you are not sure, please let us know.
-==24023== Either way, Valgrind will now raise a SIGILL signal which will
-==24023== probably kill your program.
-==24023==
-==24023== Process terminating with default action of signal 4 (SIGILL)
-==24023== Illegal opcode at address 0x420D234
-==24023== at 0x420D234: abort (abort.c:124)
-\endverbatim
-
This is the sign that you didn't used the exception mecanism well. Most
probably, you have a <tt>return;</tt> somewhere within a <tt>TRY{}</tt>
block. This is <b>evil</b>, and you must not do this. Did you read the section
\verbatim export VALGRIND_OPTS="--leak-check=yes --leak-resolution=high --num-callers=40 --tool=memcheck --suppressions=$HOME/.valgrind.supp" \endverbatim
+\subsubsection faq_trouble_backtraces Truncated backtraces
+
+When debugging SimGrid, it's easier to pass the
+--disable-compiler-optimization flag to the configure if valgrind or
+gdb get fooled by the optimization done by the compiler. But you
+should remove these flag when everything works before going in
+production (before launching your 1252135 experiments), or everything
+will run only one half of the true SimGrid potential.
+
\subsection faq_deadlock There is a deadlock in my code!!!
Unfortunately, we cannot debug every code written in SimGrid. We
*/
+******************************************************************
+* OLD CRUFT NOT USED ANYMORE *
+******************************************************************
+
+
+\subsection faq_crosscompile Cross-compiling a Windows DLL of SimGrid from linux
+
+At the moment, we do not distribute Windows pre-compiled version of SimGrid
+because the support for this platform is still experimental. We know that
+some parts of the GRAS environment do not work, and we think that the others
+environments (MSG and SD) have good chances to work, but we didn't test
+ourselves. This section explains how we generate the SimGrid DLL so that you
+can build it for yourself. First of all, you need to have a version more
+recent than 3.1 (ie, a SVN version as time of writting).
+
+In order to cross-compile the package to windows from linux, you need to
+install mingw32 (minimalist gnu win32). On Debian, you can do so by
+installing the packages mingw32 (compiler), mingw32-binutils (linker and
+so), mingw32-runtime.
+
+You can use the VPATH support of configure to compile at the same time for
+linux and windows without dupplicating the source nor cleaning the tree
+between each. Just run bootstrap (if you use the SVN) to run the autotools.
+Then, create a linux and a win directories. Then, type:
+\verbatim cd linux; ../configure --srcdir=.. <usual configure flags>; make; cd ..
+cd win; ../configure --srcdir=.. --host=i586-mingw32msvc <flags>; make; cd ..
+\endverbatim
+The trick to VPATH builds is to call configure from another directory,
+passing it an extra --srcdir argument to tell it where all the sources are.
+It will understand you want to use VPATH. Then, the trick to cross-compile
+is simply to add a --host argument specifying the target you want to build
+for. The i586-mingw32msvc string is what you have to pass to use the mingw32
+environment as distributed in Debian.
+
+After that, you can run all make targets from both directories, and test
+easily that what you change for one arch does not break the other one.
+
+It is possible that this VPATH build thing breaks from time to time in the
+SVN since it's quite fragile, but it's granted to work in any released
+version. If you experience problems, drop us a mail.
+
+Another possible source of issue is that at the moment, building the
+examples request to use the gras_stub_generator tool, which is a compiled
+program, not a script. In cross-compilation, you need to cross-execute with
+wine for example, which is not really pleasant. We are working on this, but
+in the meanwhile, simply don't build the examples in cross-compilation
+(<tt>cd src</tt> before running make).
+
+Program (cross-)compiled with mingw32 do request an extra DLL at run-time to be
+usable. For example, if you want to test your build with wine, you should do
+the following to put this library where wine looks for DLLs.
+\verbatim
+cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/
+gunzip ~/.wine/c/windows/system/mingwm10.dll.gz
+\endverbatim
+
+The DLL is built in src/.libs, and installed in the <i>prefix</i>/bin directory
+when you run make install.
+
+If you want to use it in a native project on windows, you need to use
+simgrid.dll and mingwm10.dll. For each DLL, you need to build .def file
+under linux (listing the defined symbols), and convert it into a .lib file
+under windows (specifying this in a way that windows compilers like). To
+generate the def files, run (under linux):
+\verbatim echo "LIBRARY libsimgrid-0.dll" > simgrid.def
+echo EXPORTS >> simgrid.def
+nm libsimgrid-0.dll | grep ' T _' | sed 's/.* T _//' >> simgrid.def
+nm libsimgrid-0.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> simgrid.def
+
+echo "LIBRARY mingwm10.dll" > mingwm10.def
+echo EXPORTS >> mingwm10.def
+nm mingwm10.dll | grep ' T _' | sed 's/.* T _//' >> mingwm10.def
+nm mingwm10.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> mingwm10.def
+\endverbatim
+
+To create the import .lib files, use the <tt>lib</tt> windows tool (from
+MSVC) the following way to produce simgrid.lib and mingwm10.lib
+\verbatim lib /def:simgrid.def
+lib /def:mingwm10.def
+\endverbatim
+
+If you happen to use Borland C Builder, the right command line is the
+following (note that you don't need any file.def to get this working).
+\verbatim implib simgrid.lib libsimgrid-0.dll
+implib mingwm10.lib mingwm10.dll
+\endverbatim
+
+Then, set the following parameters in Visual C++ 2005:
+Linker -> Input -> Additional dependencies = simgrid.lib mingwm10.lib
+
+Just in case you wonder how to generate a DLL from libtool in another
+project, we added -no-undefined to any lib*_la_LDFLAGS variables so that
+libtool accepts to generate a dynamic library under windows. Then, to make
+it true, we pass any dependencies (such as -lws2 under windows or -lpthread
+on need) on the linking line. Passing such deps is a good idea anyway so
+that they get noted in the library itself, avoiding the users to know about
+our dependencies and put them manually on their compilation line. Then we
+added the AC_LIBTOOL_WIN32_DLL macro just before AC_PROG_LIBTOOL in the
+configure.ac. It means that we exported any symbols which need to be.
+Nowadays, functions get automatically exported, so we don't need to load our
+header files with tons of __declspec(dllexport) cruft. We only need to do so
+for data, but there is no public data in SimGrid so we are good.
+
