[Rivet] Installing rivet on SL5

[Eike von Seggern]

On Tue, Oct 06, 2009 at 17:11 +0100, Andy Buckley wrote:
> Eike von Seggern wrote:
> > On Mon, Oct 05, 2009 at 13:51 +0100, Andy Buckley wrote:
> >> Eike von Seggern wrote:
> >>> Hi,
> >>>
> >>> I'm trying to install rivet 1.1.3 on x86-64-slc5-gcc43-opt.  I've
> >>> checked out the 1.1.3 tag from svn and called autoreconf -iv
> >>>
> >>> After that I used the following to configure:
> >> [...]
> >>
> >>> but compiling the python extension fails:
> >> [...]
> >>
> >>> Removing rivet.py and rivet_wrap.cc in pyext/ does not fix this but only
> >>> changes the error:
> >>>
> >>> $ CC=gcc43 CXX=g++43 make
> >>> swig -c++ -python -I/afs/cern.ch/sw/lcg/external/HepMC/2.05.00/x86_64-slc5-gcc43-opt/include -I../include -o rivet_wrap.cc rivet.i
> >>> /usr/bin/python setup.py build
> >>> running build
> >>> running build_py
> >>> copying rivet.py -> build/lib.linux-x86_64-2.4
> >>> running build_ext
> >>> building '_rivet' extension
> >>> gcc43 -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fPIC -DSWIG_TYPE_TABLE=hepmccompat -I/scratch/zn/lustre/atlas/vseggern/rivet/rivet-1.1.3-svn/include -I/afs/cern.ch/sw/lcg/external/HepMC/2.05.00/x86_64-slc5-gcc43-opt/include -I/afs/cern.ch/sw/lcg/external/Boost/1.39.0_python2.5/x86_64-slc5-gcc43-opt/include/boost-1_39 -I/afs/cern.ch/sw/lcg/external/GSL/1.10/x86_64-slc5-gcc43-opt/include -I/usr/include/python2.4 -c ./rivet_wrap.cc -o build/temp.linux-x86_64-2.4/./rivet_wrap.o
> >>> ./rivet_wrap.cc: In function ???void SWIG_Python_SetSwigThis(PyObject*, PyObject*)???:
> >>> ./rivet_wrap.cc:2172: warning: deprecated conversion from string constant to ???char*???
> >>> ./rivet_wrap.cc: In constructor ???swig::PyObject_ptr::PyObject_ptr(PyObject*, bool)???:
> >>> ./rivet_wrap.cc:2592: warning: suggest explicit braces to avoid ambiguous ???else???
> >>> ./rivet_wrap.cc: In function ???std::string HepMC_FourVector___str__(HepMC::FourVector*)???:
> >>> ./rivet_wrap.cc:3028: error: ???$self??? was not declared in this scope
> >>> [a lot more "$self was not declared" errors from other locations and some other errors]
> >>>
> >>> Has anyone an idea what I'm missing here?
> >> Missing nothing, but certainly experiencing the delights of SL5. What 
> >> you're doing is right, but the version of SWIG on SL5 is sufficiently 
> >> old that it can't parse the HepMC header file. I think the easiest way 
> >> around is to make your own hepmc.py and hepmc_wrap.cc against HepMC 2.03 
> >> (I'm assuming it's not HepMC 2.4, since that should work out of the box) 
> >> on a more up-to-date OS and then copy them into place. After the work 
> >> that Frank did last week, the head version should now do all the HepMC 
> >> compatible stuff in the C++ rather than the Python interface.
> > 
> > I see now that I was too ambitious. Trying to compile against new
> > libraries on SL5. So I changed the HepMC version to 2.04.01 and the
> > Python extension is built fine.
> > 
> > But nevertheless importing _rivet fails with:
> > 
> > ImportError: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /afs/cern.ch/sw/lcg/external/HepMC/2.04.01/x86_64-slc5-gcc43-opt/lib/libHepMC.so.2)
> > 
> > But this is probably a problem the NAF helpdesk has to solve for me...
> 
> I see this ~every time a new Rivet commit happens, as the Hudson build 
> system fails yet again to build Rivet on our test 64 bit system. I've 
> not had time to chase this down, but I think it relates to different 
> bits of the code having been built with different versions of glibc 
> (i.e. different and binary-incompatible compiler versions.) I'm not sure 
> why this happens, but SL5 is notably a complete mess when it comes to 
> compilers...
> 
> So *please* have a look into getting this working, and if you succeed, 
> let me know how!

Yes, I think it's related to an incoherent set of library versions.
E.g. in the output of

$ strings /usr/lib/libstdc++.so.6 | grep GLIBCXX

the version goes up to 3.4.8 .

The versions in /afs.../lcg/contrib go up to 3.4.10 .

Calling ldd on the respective version of libHepMC.so.2 gives that it's
linked to the AFS libstdc++, but somehow the local version is loaded.
I'm definitely a newbie with all this dynamical linking stuff and now
more than just a little bit confused ;)

Best wishes
    eike