|
[Rivet] [LHAPDF] Internal compiler errorAndy Buckley andy.buckley at durham.ac.ukThu Dec 11 12:17:52 GMT 2008
James Monk wrote: > Hi, > > I can confirm I also see this problem in LHAPDF 5.6 using gfortran > (gcc 4.4) from hpc.sourceforge.net. Did you, Chistopher, also get > gfortran from hpc? I attach my config.log to http://www.hep.ucl.ac.uk/~jmonk/lhapdf/config.log > > However, I have no such problems with lhapdf 5.3.1, which I think is > fine to use with Rivet. The neural net PDFs (the "NNPDF" in the error) are new in 5.6.0, so I think that any version up to 5.5.x should be okay. This will need to be investigated and fixed for LHAPDF 5.6.1. > I notice that a difference in the build > options between the two is that 5.6 adds -ffree-form to gfortran > compilation. I googled free-form to try and discover what it does, > and a lot of the hits are bug discussions for OS X! In any case, free- > form specifies that he code is using a new (post fortran 90) dialect > of fortran. I would have thought LHAPDF would want to be compatible > with g77, in which case free-form should not be necessary. Actually, the core LHAPDF infrastructure code was moved to F90 in version 5.5.0 (I think) to resolve a fundamental problem with common block initialisation in the modern world of shared libraries (how the BLOCK DATA initialisation actually works is very, very ugly, and doesn't port to non-monolithic code --- F90 modules solve the problem). Due to LCG restrictions, we backtracked and hacked in a sort-of-reliable way to initialise the common blocks, but the free-form source formatting remains. Andy -- Dr Andy Buckley Institute for Particle Physics Phenomenology Durham University 0191 3343798 | 0191 3732613 | www.insectnation.org
More information about the Rivet mailing list |