(Uncommon) Build Problems

Here's a list of not so common problems that you might encounter when building WHIZARD that didn't make it into the INSTALL file​.

Compiling in the Source Directory

If you don't take advantage of the possibility to keep your WHIZARD sources pristine by compiling in a different directory, you may encounter the following error with the sources in whizard-2.0.0.tar.gz:

...
libtool: compile:  gfortran45 -I../misc -I../vamp -g -O2 -c processes.f90  -fPIC -o .libs/processes.o
libtool: compile:  gfortran45 -I../misc -I../vamp -g -O2 -c processes.f90 -o processes.o >/dev/null 2>&1
make[2]: *** No rule to make target `limits.lo', needed by `decays.lo'.  Stop.
...
make: *** [all-recursive] Error 1

In this case, please unpack a fresh copy of WHIZARD and configure it in a separate directory (not necessarily a subdirectory). Then the compilation will go through

$ zcat whizard-2.0.0.tar.gz | tar xf - 
$ cd whizard-2.0.0
$ mkdir _build
$ cd _build
$ ../configure FC=gfortran-4.5
$ make

(The developers use this setup to be able to test different compilers. Therefore building in the same directory is not as thoroughly tested. There will be a patch release correcting such minor problems soon.)

Compiler and Shared Library search PATHs

If you are using gfortran, you will have to locally install a version >= 4.5 as current linux distributions don't yet ship 4.5. This is not very hard to do and causes absolutely no harm. However, you have to make sure that the environment is configured correctly when building and running WHIZARD:

   export PATH=<path to the gfortran-4.5 binary>:$PATH
   export LD_LIBRARY_PATH=<path to the gfortran-4.5-libraries>:$LD_LIBRARY_PATH

While the soname of the gfortran runtime has not changed, some of the internal changes are crucial for the operation of WHIZARD, and you will get weird runtime errors if WHIZARD links to old compiler's runtime libraries.

Parallel Make and Slow Filesystems

The current version of O'Mega uses intermediate files in .../var/cache/ to store precomputed vertex tables in order to significantly increase the startup speed for complicated BSM models with many new particles and vertices. These files are generated as needed and require no user intervention.

Unfortunately, if several copies of O'Mega for the same model are running simultaneously and for the very first time, they might encounter an incomplete version of the vertex table. In practice, this almost never a problem, but if you run make check with the -j option (parallel execution) on slow networked file systems, a few checks might fail. In this case, just rerun make check without the -j option to force sequential execution. However, after the first make check, all subsequent make check should work even with the -j option.

NB: O'Mega will never produce a wrong nonvanishing matrix element due to the rare race condition described above. The only possible symptom is a vanishing scattering amplitude. Nevertheless, we aim to make the cache files obsolete by an equivalent, but faster algorithm in milestone:v2.1 (cf. ticket #271).

Incompatibility with O'Caml 3.12.0

Unfortunately, the latest and greatest version of the O'Caml compiler - 3.12.0 - broke backwards compatibility. Therefore, versions of O'Mega / WHIZARD up to 2.0.2 only compile with older versions (3.11.x works). This has been fixed in 2.0.3.

MAC OS X specifics

For MAC OS X we highly discourage to use any of the available builds of gfortran 4.5.0 which are still experimental, though some of them work, many of them are from an earlier stage of gcc/gfortran development and do not compile WHIZARD correctly or produce runtime errors (e.g. garbage in character string expressions and all that). A MAC OS X build of gfortran 4.5.0 (official release version) for Darwin 10.6.3 is available from ​this link.