[Rivet] Installing rivet on SL5

[Eike von Seggern]

On Tue, Oct 06, 2009 at 18:32 +0200, Eike von Seggern wrote:
> 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 ;)

So, I think I've managed to build rivet:

I added
/afs/.cern.ch/sw/lcg/contrib/gcc/4.3.2/slc4_amd64_gcc34/lib64
to my LD_LIBRARY_PATH because libHepMC.so.2 needs the libstdc++ in here
(it's the GLIBCXX version issue mentioned above).

$ CC=gcc43 CXXCC=g++43 ./configure --prefix=/scratch/zn/lustre/atlas/vseggern/local-sl5/
--with-lcgtag=x86-64-slc5-gcc43-opt
--with-boost=/afs/cern.ch/sw/lcg/external/Boost/1.39.0_python2.5/x86_64-slc5-gcc43-opt
--with-boost-incpath=/afs/cern.ch/sw/lcg/external/Boost/1.39.0_python2.5/x86_64-slc5-gcc43-opt/include/boost-1_39
--with-hepmc=/afs/cern.ch/sw/lcg/external/HepMC/2.04.01/x86_64-slc5-gcc43-opt
--with-fastjet=/afs/cern.ch/sw/lcg/external/fastjet/2.4.1/x86_64-slc5-gcc43-opt
--with-gsl=/afs/cern.ch/sw/lcg/external/GSL/1.10/x86_64-slc5-gcc43-opt

then I called make && make install and added the appropriate paths to
LD_LIBRARY_PATH:

$ echo $LD_LIBRARY_PATH
/afs/.cern.ch/sw/lcg/contrib/gcc/4.3.2/slc4_amd64_gcc34/lib64:/scratch/zn/current/atlas/vseggern/local-sl5/lib:/afs/cern.ch/sw/lcg/external/Boost/1.39.0_python2.5/x86_64-slc5-gcc43-opt/lib:/afs/cern.ch/sw/lcg/external/HepMC/2.04.01/x86_64-slc5-gcc43-opt/lib:/afs/cern.ch/sw/lcg/external/fastjet/2.4.1/x86_64-slc5-gcc43-opt/lib:/afs/cern.ch/sw/lcg/external/GSL/1.10/x86_64-slc5-gcc43-opt/lib

Now I can call

$ rivet
Reading events from '-'
[Ctrl-C]
IO_GenEvent::fill_next_event start key not found setting badbit.
Signal handler called with signal 2
zsh: 23284 segmentation fault  rivet

The above is probably okay?

But now Sherpa 1.2.0 fails to compile, complaining about undefined
references to

... undefined reference to `... @GLIBCXX_3.4.9'

Welcome back to version hell :-/

tschuess
    eike