[Rivet] undefined MAIN?

[Andy Buckley]

On 18/01/10 21:23, James Monk wrote:
> Back to this problem again as I am trying to install a release
> candidate in AFS.
> 
> One difference I have discovered is in the fortran libraries used.
> The amd64 library (the one that works) uses e.g.:
> 
> -L/usr/lib/../lib64 -lgfortranbegin -lgfortran
> 
> Whereas on a 32 machine it links
> 
> /afs/.cern.ch/sw/lcg/contrib/gcc/4.3.2/slc4_ia32_gcc34/lib/gcc/i686-pc-linux-gnu/4.3.2/libgfortranbegin.a
>
> 
> and later
> /afs/.cern.ch/sw/lcg/contrib/gcc/4.3.2/slc4_ia32_gcc34/lib/libgfortran.so
>
>  So the ordering is different (libgfortranbegin is near the start of
> the linker on 32 bit)  and they are quite possibly different versions
> of libgfortran/begin.  libgfortranbegin has a load of main-ish
> symbols in it, doesn't it? so if that is getting statically linked
> into the Rivet library then I *think* that explains it.
> 
> Question now is, what is pulling in libgfortranbegin.a?

No idea... this is really weird. There's no Fortran compiler anywhere
near Rivet... and I don't *think* we're ever linking against Fortran
libraries. The closest things I can think of are the fastjet libs (and
HepMCfio, but we're not using that in Rivet... AGILe yes, Rivet no). Any
obvious calls to the Fortran libraries in the "make" output,
particularly the final lib-linking step? And do the Genser fastjet
builds a) have these (undefined) symbols in them / are they properly
built as shared libs?

Currently mystified... I've never seen this happen, personally, so I
guess it's an SLC5 / GENSER oddity triggering some nasty behaviour!

Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh