[Rivet] undefined MAIN?

[James Monk]

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?  

cheers,

James

On 21 Dec 2009, at 21:12, Andy Buckley wrote:

> On 21/12/09 00:17, James Monk wrote:
>> Some more information:  this only seems to happen when I build on a 32
>> bit machine for slc4_ia32 - slc4_amd64 seems to work.
>> 
>> Perhaps one of the Genser ia32 libs Rivet depends on is incorrectly built?
> 
> Certainly possible, but my quick checks of HepMC and fastjet don't show any such symbols. The only other external libraries are Boost and GSL, which don't seem likely.
> 
> You need to dig into what Rivet's being linked against on that platform, I'm afraid! Might be easiest to use ldd or objdump -p on the built libRivet.so with the MAIN__ symbol and see if any of the chained libraries have it.
> 
> Andy
> 
> -- 
> Dr Andy Buckley
> SUPA Advanced Research Fellow
> Particle Physics Experiment Group, University of Edinburgh