Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Investiguated a bit the problems we have with gcc-4.0. Let's document what I've found...
[simgrid.git] / doc / FAQ.doc
index 7d0bceb..d14f7ea 100644 (file)
@@ -11,7 +11,7 @@ not familiar with compiling C files under UNIX. If you follow these
 instructions and still have some troubles, drop an e-mail to
 <simgrid-user@lists.gforge.inria.fr>.
 
-\subsection faq_compiling Compiling SimGrid
+\subsection faq_compiling Compiling SimGrid from an 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>.
@@ -68,18 +68,25 @@ Thus, there is two ways to link your program with SimGrid:
 
 \subsection faq_compiling_cvs Compiling SimGrid from the CVS
 
-First of all, you need to get the "simgrid" module from
+The project development takes place in the cvs, where all changes are
+commited 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
+CVS. We afterward go back to the development in the CVS. So, if you need a
+recently added feature and can afford some little problem with the stability
+of the lastest features, you may want to use the CVS version instead of a
+released one.
+
+For that, you first need to get the "simgrid" module from
 <a href="http://gforge.inria.fr/scm/?group_id=12">here</a>. 
 
 You won't find any <tt>configure</tt> and a few other things
-(<tt>Makefile.in</tt>'s, documentation, ...) will be missing as
-well. The reason for that is that all these files have to be
-regenerated using the latest versions of <tt>autoconf</tt>,
-<tt>automake</tt> (1.9) and <tt>doxygen</tt>. To generate the
-<tt>configure</tt> and the <tt>Makefile.in</tt>'s, you just have to
-launch the <tt>bootstrap</tt> command that resides in the top of the
-source tree. Then just follow the instructions of Section 
-\ref faq_compiling.
+(<tt>Makefile.in</tt>'s, documentation, ...) will be missing as well. The
+reason for that is that all these files have to be regenerated using the
+latest versions of <tt>autoconf</tt>, <tt>libtool</tt>, <tt>automake</tt>
+(>1.9) and <tt>doxygen</tt> (>1.4). To generate the <tt>configure</tt> and
+the <tt>Makefile.in</tt>'s, you just have to launch the <tt>bootstrap</tt>
+command that resides in the top of the source tree. Then just follow the
+instructions of Section \ref faq_compiling.
 
 We insist on the fact that you really need the latest versions of
 autoconf and automake. Doing this step on exotic architectures/systems
@@ -89,6 +96,17 @@ architecture/system, you should do the previous steps on a perfectly
 standard box, then do a <tt>make dist</tt> that will build you a
 perfectly portable SimGrid archive.
 
+In summary, the following commands will checkout the CVS, regenerate the
+configure script and friends, configure SimGrid and build an archive you can
+use on another machine afterward.
+
+\verbatim cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid login
+cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid checkout simgrid
+cd simgrid
+./bootstrap
+./configure --enable-maintainer-mode
+make dist \endverbatim
+
 \subsection faq_setting Setting up your own code
 
 Do not build your simulator by modifying the SimGrid examples.  Go
@@ -757,10 +775,23 @@ machine:
  - <b>You are using a borken compiler</b>.\n
    The symptom may be that the "make check" fails within testsuite/gras
    directory.\n
-   For example, the breezy release of Ubuntu comes with a prerelease of the
-   4.0 gcc compiler. This version happens to be completely unusable, and you
-   should install a gcc-3.4 compiler and change the /usr/bin/gcc link to let
-   it point on /usr/bin/gcc-3.4.
+   For example, we failed to use gcc 4.0 with optimization flags. The
+   workaround is either to install a gcc-3.4 compiler and change the /usr/bin/gcc 
+   link to let it point on /usr/bin/gcc-3.4 or use the
+   --disable-compiler-optimizations of the configure script.\n
+   This bug is really puzzeling: the first testcase of gras fails when
+   SimGrid is compiled with any optimization flag (-O1 and above). More
+   astonishing, it also fails when compiled with 
+   <tt>-O1 -fno-defer-pop -fno-guess-branch-probability -fno-cprop-registers -fno-loop-optimize -fno-if-conversion -fno-if-conversion2 -fno-merge-constants -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra -fno-tree-copyrename -no-ftree-fre -fno-tree-ch -fno-delayed-branch</tt>\n
+   That long list of options comes down to enabling -O1, and then disabling
+   all the optimizations that -O1 is supposed to enable, according to the
+   gcc documentation. So, it should give the same results than -O0... The
+   reason seems to be this little sentence in the gcc documentation: <i>Not
+   all optimizations are controlled directly by a flag.  Only optimizations
+   that have a flag are listed.</i> Under such circumstances, there is not
+   much we can do.\n
+   <b>=> Avoid gcc-4.0 when compiling SimGrid!</b>
+   
  - <b>You are using a borken 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
@@ -778,7 +809,9 @@ machine:
    concurently, 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.
+   software even if it's so troublesome.\n
+   <b>=> use --with-pthread on AMD64 architecture</b>
+   
  - <b>There is a bug in SimGrid we aren't aware of</b>.\n
    If none of the above apply, please drop us a mail on the mailing list so
    that we can check it out.
@@ -822,7 +855,8 @@ Here are some tricks I had to use in order to run a token ring between
 
  - 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
-   want to adapt to your case.
+   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 the FAQ
    entry \ref faq_flexml_limit
@@ -964,6 +998,18 @@ list. Just be aware that you'll be severely punished if the mistake is
 on your side... We have plenty of FAQ entries to redact and new
 features to implement for the impenitents! ;)
 
+\subsection faq_big_fat_warning A BIG FAT WARNING is reported telling me that my platform and deployment 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:
+\verbatim
+  <platform_description version="1">
+\endverbatim
+You should try to use the surfxml_update.pl script that can be found
+<a href="http://gforge.inria.fr/plugins/scmcvs/cvsweb.php/contrib/platform_generation/?cvsroot=cvsroot%2Fsimgrid">here</a>.
+  
 \author Arnaud Legrand (arnaud.legrand::imag.fr)
 \author Martin Quinson (martin.quinson::loria.fr)