Genser Build Issues
- We need to be able to build and use the Genser generator packages on systems which are not standard LCG platforms: they do not have the CERN AFS area mounted, and are not necessarily running a RedHat-derived Linux (Fedora Linux, Ubuntu Linux, and Mac OS X are also in heavy use by our developers and users). The Genser build system is very specific in assuming both the existence of hard-coded AFS paths and also the identities of compilers and is not easily or robustly portable to other platforms. This fragility probably also extends to upgrades of the LCG OS. We (CEDAR) already have been maintaining portable autoconf packages of several generators, which we would be happy to adapt to Genser's needs (e.g. AFS tag) and donate to Genser. We believe that cited difficulties with autotools installations can very probably be avoided with minimal changes to Genser procedure.
- It would be extremely useful if Genser had a bug tracker, e.g. on CERN Savannah, so that specific problems and requests like those below can be registered, assigned, discussed and tracked. Actually, it has one: https://savannah.cern.ch/projects/genser/ and bug tracker at https://savannah.cern.ch/bugs/?group=genser . It doesn't look like it's used much, though, since only 2 bugs have ever been recorded and one of those hasn't been assigned despite being submitted in July 2007...
- We request a defined, programmatically predictable structure to the Genser AFS area, such that the AGILe generator interface can automatically decide where to load its generators from.
- We request a published, portable script for building a local version of the Genser AFS area for systems without AFS mounted, or which are not standard platforms with an LCG platform tag supported by Genser.
- $(CXX) is used in the Genser makefiles to link Fortran shared libraries, resulting in Fortran libraries depending on the C++ std libs, but not declaring or handling their real dependency on the Fortran std libraries. Since there are several Fortran compilers, it's not reliable to work around this by compiling rivetgun against a particular Fortran std lib. The fix for this is a simple change in the Makefile from $(CXX) to $(FC) in one place.
- The Genser configure scripts declare that they want to be interpreted by the sh interpreter, and then use constructs which belong to bash rather than sh. This breaks on e.g. Ubuntu systems, and that it works on Scientific Linux is coincidental.
- Forces g77 unless it detects an LCG tag of "Linux-gcc4," in which case it uses gfortran. There are more than two fortran compilers in existence and not all are in use under linux!
- Gets the arguments to build dynamic shared libs on OS X completely wrong (-dynamiclib -undefined dynamic_lookup should replace -shared -soname,$@).
- -fPIC! No!! (actually it's -fpic you want to avoid, fPIC is default on OS X)
- .dylib rather than .so please
- Tab/space issues/warnings with gfortran "Warning: Nonconforming tab character in column 1 of line 55" etc. etc. When libtool steers gfortran this doesn't happen (same Herwig code I presume).
- Possible library name conflict libherwig.dylib (fortran) Vs. libHerwig.dylib (C++) on case insensitive file system. HFS+ is in fact case sensitive, but nobody ever enables case-sensitivity because it breaks legacy code in applications like Adobe Photoshop etc. AB: I don't think this is a problem - we can use a "liblinks" directory or be careful to specify absolute paths in our generator dlopening function.
- Charybdis and Jimmy assumes existence of particular Herwig (and Pythia) versions and a mounted /afs/cern.ch/... area.
- Pythia 8 assumes it's being built on a system with /afs/cern.ch/... when it looks for HepMC.
Download all attachments as: .zip
Download in other formats: