[Rivet] Installing rivet on SL5

[Eike von Seggern]

Okay, summarizing my installation-rally for Rivet 1.1.3-svn on SL5
building against libraries in CERN AFS space. The thing I did wrong all
the time was assuming that the libraries were built using the
SL5-shipped compilers. That's not the case I know now. So the following
steps worked for me to get a working Rivet+Shera installation:

1. Set-up CERN's gcc environment:
$ source /afs/cern.ch/sw/lcg/contrib/gcc/4.3/x86_64-slc5-gcc43-opt/setup.sh

2. Configure Rivet using the appropriate directories:
$ ./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

and build/install it. Do the same for Sherpa...

Include appropriate settings in your startup files. For me that's
.zshenv:

echo "Setting environment for SL 5.3"

## set gcc43 paths for genser
source /afs/cern.ch/sw/lcg/contrib/gcc/4.3/x86_64-slc5-gcc43-opt/setup.sh

RIVETPATH="/scratch/zn/current/atlas/vseggern/local-sl5"
if [[ -d $RIVETPATH ]]; then
    export PATH=$PATH:$RIVETPATH/bin
    export PYTHONPATH=$RIVETPATH/lib64/python2.4/site-packages:$PYTHONPATH
    export LD_LIBRARY_PATH=$RIVETPATH/lib:$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH=/afs/cern.ch/sw/lcg/external/Boost/1.39.0_python2.5/x86_64-slc5-gcc43-opt/lib:$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH=/afs/cern.ch/sw/lcg/external/HepMC/2.04.01/x86_64-slc5-gcc43-opt/lib:$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH=/afs/cern.ch/sw/lcg/external/fastjet/2.4.1/x86_64-slc5-gcc43-opt/lib:$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH=/afs/cern.ch/sw/lcg/external/GSL/1.10/x86_64-slc5-gcc43-opt/lib:$LD_LIBRARY_PATH
fi


NB: I used to have this in .zprofile (= .profile for bash) but this only
read on login and not when I open a screen session, which itself strips
$LD_LIBRARY_PATH for security reasons. Whereas .zshenv is run for every
new zsh-session. The drawback is that $PATH is not cleared and contains
duplicates when using screen.

Hope this helps a little.

tschuess
    eike


On Wed, Oct 07, 2009 at 15:28 +0200, Eike von Seggern wrote:
> > > > 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