"Out-Of-The-Box" WHIZARD

[Boschmann]

This is going to be a tarball including everything WHIZARD needs to run. The first goal is a tarball, that works with a virgin debian-505-netinst installation.

My suggested directory hiracy:

\opt\whizard-ootb\
........................+-> gcc\
........................+-> lhapdf\
........................+-> ocaml\
........................+-> whizard\

[Christian Speckner]

I was more thinking about a tarball which decompresses like:

instant-whizard/
...............bin/
...............lib/
...............share/
...............include/
...............setup-whizard.sh

where setup-whizard.sh is a shell script which can be sourced to setup the local environment (${PATH} and friends) such that WHIZARD can be used like anything else. This has the big advantage that no root permissions would be required to use the tarball (an admin can still put the thing into /opt and setup the global env accordingly).

[ohl]

CS is right, IMHO.

[Boschmann]

OK. How can I protect links from breaking when I move the whole directory to /opt? Usually, programs don't run anywhere else but in the dir in --prefix=dir.

For now, I only include gcc, lhapdf and ocaml. Is it worthwhile to include HepMC, PYTHIA, HERWIG or FeynRules? someday? (I will never touch ROOT!)

[Boschmann]

FIRST VERSION OF INSTANT-WHIZARD

​http://event-generator.tp1.physik.uni-siegen.de/hudson/instant-whizard/

When you have a linux system that is NOT prepared for software development, then please test instant-whizard on it.

[Christian Speckner]

OK, I've played around with it a bit, here are my comments:

1) As it stands, the tarball is locked to /opt --- I think that this is a bad idea, it should be usable for a user without root privileges by just untarring it in his home directory. Changing install.sh to

INSTALLATION=""

if [ -z "${INSTALLATION}" ]; then
   echo "please set INSTALLATION in install.sh correctly before using instant-WHIZARD."
else
   export PATH="${INSTALLATION}/bin:${PATH}"
   export LD_LIBRARY_PATH="${INSTALLATION}/lib:${LD_LIBRARY_PATH}"
   export MANPATH="${INSTALLATION}/share/man:${MANPATH}"
   alias whizard="whizard --prefix \"${INSTALLATION}\""
fi

and symlinking the libraries in lib/whizard and friends to lib, I get quite far as a mundane user, up to the point where WHIZARD looks for libtool in /opt. Consequently, I have changed libtool path handling in r2783 to honor the --prefix option, should work with the next instant-whizard build.

Concerning you --prefix concerns: gcc is not so fragile here, it uses relative paths whenever applicable, and WHIZARD can be tamed using the --prefix option. O'Caml is more tricky, but can also be tamed using the correct options. The only issue is compiling FeynRules? models, but I already have an idea for a workaround; I'll work on it when I find time.

2) On my old Pentium II laptop I have used for testing, after creating a symlink to libtool in the right location, I get

<built-in>:0:0: internal compiler error: Ungueltiger Maschinenbefehl

from gfortran. It looks like gcc has been compiled for i686, could you trim this down to i586 or even i386 (I don't think the speed penality will be large)?

3) What's that i568 chip you are talking about? ;)

[Boschmann]

1): Thanks, I have merged your shell script into mine. But I wait for the next release of WHIZARD instead of using the latest svn revision.

2) and 3): It was build on a pentium 4 and was supposed to run on all pentium cpus, but the instruction downgrade didn't work. I did some research but couldn't find the reason yet. Therefore I will not make a 'real' i586 binary soon. But I have given better names to the tarballs and have included 'BUILD_INFO' files. The particular cpu of the build system is given there. It's a pentium 4 for the i686 binary and a Athlon 64 for the amd64 binary.

[Boschmann]

instant-whizard-i386-Darwin-2.0.3 is available

It is build on Mac Os X 10.6.4. uname -p says 'i386', but I didn't check the binary on a real 386 cpu.

[Juergen Reuter]

Please comment: what is actually left to do here? Is this somehow automatized that always the newest versions are being built?

[Christian Speckner]

I would only consider this complete when the tarball has reached the point where it can run locally without requiring to be untarred to /opt. Otherwise, it is completely useless for anyone using it on a machine where he / she doesn't have root access, and a would wager that this covers about 90% of the potential usage cases. With the change I made, this should be possible, but as Hans is only building releases, it will have to wait for 2.0.4.

[Boschmann]

I thought that there is still a problem with compiling FeynRules?. When you believe that whizard is fully relocatable now, then I can try to make a svn-instand-whizard and close the ticked on success. I just didn't want to recompile instant-whizard for every revision.

[Christian Speckner]

It is true that compiling Feynfules models will still fail, but this can be fixed by adding an alias for ocamlopt.opt to the setup script which adds the ocaml directory explicitly to the command line. Still, I wouldn't worry about this too much, once the tarball works, I can do this quickly.

[Juergen Reuter]

Ok, when this will be ready after the 2.0.4 release, I move it to 2.0.5.

[Boschmann]

I've tested relocatability of the actual revision 2823, but it failed. Here is what I've done:

 configure -prefix=/opt/instant-whizard
 make all install
 mv /opt/instant-whizard /opt/instant-whizard-2823
 export PATH=/opt/instant-whizard-2823/bin:$PATH
 export LD_LIBRARY_PATH=/opt/instant-whizard-2823/lib
 whizard --prefix /opt/instant-whizard-2823/ --version

The result is:

 dyld: Library not loaded: /opt/instant-whizard/lib/whizard/libwhizard_main.0.dylib
 Referenced from: /opt/instant-whizard-2823/bin/whizard
 Reason: image not found
 Trace/BPT trap

Have I done it wrong? Or is whizard still not relocatable?

[Christian Speckner]

There are two problems here: on Mr. Jobs junkpiles, it is DYLD_LIBRARY_PATH, not LD_LIBRARY_PATH. In addition, you have to take care to get all libraries into the path, export DYLD_LIBRARY_PATH=/opt/instant-whizard-2823/lib won't suffice as there are several subdirectories with the libraries for O'Mega, vamp and WHIZARD. I would suggest symlinking their contents to the main libdir in the tarball.

[Boschmann]

Thank you, I will change this in the darwin release. I still get some error messages, but for a different reason. Nevertheless, I can not declare this ticket as "fixed" until I get an executable release.

[Boschmann]

Whizard is still not relocatable. I've tried to run the examples like this:

./configure -prefix=/tmp
make 
make DESTDIR=/var/lib/jenkins/.hudson/jobs/foo/workspace/whizard-trunk-install-2991 install
(setting some environment variables...)
whizard --prefix /var/lib/jenkins/.hudson/jobs/foo/workspace/whizard-trunk-install-2991 casc_dec.sin

The result is:

(...)
/usr/bin/grep: /tmp/lib/vamp/libvamp.la: No such file or directory
/usr/bin/sed: can't read /tmp/lib/vamp/libvamp.la: No such file or directory
libtool: link: `/tmp/lib/vamp/libvamp.la' is not a valid libtool archive
| command: /var/lib/jenkins/.hudson/jobs/foo/workspace/whizard-trunk-install-2991/lib /whizard/libtool --mode=link gfortran -module -rpath /usr/local/lib  -g -O2 -L/var /lib/jenkins/.hudson/jobs/foo/workspace/whizard-trunk-install-2991/lib/whizard-lwhizard_main -lwhizard -lomega    -o 'processes.la'  dec_su_q.lo dec_neu_sl2.lo susybg.lo full.lo processes.lo -L/var/lib/jenkins/.hudson/jobs/foo/workspace/whizard-trunk-install-2991/lib/whizard -lwhizard_main -lwhizard -lomega    -L/var/lib/jenkins/.hudson/jobs/foo/workspace/whizard-trunk-install-2991/lib/whizard/models
| Return code = 256

[Boschmann]

There is something more about DESTDIR:

When you run ./configue -prefix=$PREFIX
make DESTDIR=$DESTDIR install

then make will put some files

omega_QCD.vertices
omega_QED.vertices
omega_SM.vertices

into $PREFIX/var/cache/ When $PREFIX/var/cache/ is not accessible, then make fails to install the binaries.

[Boschmann]

I believe that I can close this ticket as soon as #224 gets fixed.

[Juergen Reuter]

#224 has been fixed, we have a blue blob on the Jenkins for the instant (a.k.a. as out-of-the-box WHIZARD).... so whats the status here? DOes it mean from 2.0.5 on we have OftBW?

[Boschmann]

I have build an instant-whizard, but didn't test it yet. I need a clean linux installation without development environment, that's why I have set up a virtual debian 6 client. When it works, the I close the ticket.

[Boschmann]

Finally I made it work on a virgin debian 6 64-bit system. Instant-whizard now contains:

• autoconf
• automake
• gcc-4.6.0
• gmp
• lhapdf + default pdf sets
• libtool
• m4
• make
• mpc
• mpfr
• ocaml
• whizard

There is still work to do like testing on other platforms, but whizard is relocatable now so I close this ticket.