X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/bc0a801f43c2f629b14e3e6153924fecf6ee9ec5..a944cb21725f0ddd339cb7a7dc30d249c8a0cae7:/doc/doxygen/FAQ.doc diff --git a/doc/doxygen/FAQ.doc b/doc/doxygen/FAQ.doc index 11b7ba90f3..44e4f9aaa7 100644 --- a/doc/doxygen/FAQ.doc +++ b/doc/doxygen/FAQ.doc @@ -49,19 +49,16 @@ We also have a more graphical output. Have a look at section \ref options_tracin \subsection faq_C Argh! Do I really have to code in C? -Currently bindings on top of MSG are supported for Java, Ruby and Lua. You can find a few -documentation about them on the doc page. Note that bindings are released separately from the main dist -and so have their own version numbers. +We provide Java bindings of the MSG interface, which is the main +SimGrid user API. -Moreover If you use C++, -you should be able to use the SimGrid library as a standard C library -and everything should work fine (simply link against this -library; recompiling SimGrid with a C++ compiler won't work and it -wouldn't help if you could). +Moreover If you use C++, you should be able to use the SimGrid library +as a standard C library and everything should work fine (simply +link against this library; recompiling SimGrid with a C++ +compiler won't work and it wouldn't help if you could). -For now, -we do not feel a real demand for any other language. But if you think there is one, - please speak up! +For now, we do not feel a real demand for any other language. But if +you think there is one, please speak up! \section faq_howto Feature related questions @@ -480,7 +477,7 @@ do so. \subsubsection faq_trouble_err_logcat "gcc: _simgrid_this_log_category_does_not_exist__??? undeclared (first use in this function)" -This is because you are using the log mecanism, but you didn't created +This is because you are using the log mechanism, but you didn't created any default category in this file. You should refer to \ref XBT_log for all the details, but you simply forgot to call one of XBT_LOG_NEW_DEFAULT_CATEGORY() or XBT_LOG_NEW_DEFAULT_SUBCATEGORY(). @@ -592,7 +589,7 @@ This is when valgrind starts complaining about longjmp things, just like: ==21434== at 0x420DC3A: __longjmp (__longjmp.S:48) \endverbatim -This is the sign that you didn't used the exception mecanism well. Most +This is the sign that you didn't used the exception mechanism well. Most probably, you have a return; somewhere within a TRY{} block. This is evil, and you must not do this. Did you read the section about \ref XBT_ex?? @@ -656,7 +653,7 @@ will run only one half of the true SimGrid potential. Unfortunately, we cannot debug every code written in SimGrid. We furthermore believe that the framework provides ways enough -information to debug such informations yourself. If the textual output +information to debug such information yourself. If the textual output is not enough, Make sure to check the \ref faq_visualization FAQ entry to see how to get a graphical one. @@ -731,106 +728,3 @@ specific at all, but it's full of good advices). \author Da SimGrid team */ - -****************************************************************** -* 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=.. ; make; cd .. -cd win; ../configure --srcdir=.. --host=i586-mingw32msvc ; 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 -(cd src 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 prefix/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 lib 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.