Fermilab


MINOS Offline Documentation
[home] [installing MINOS software] [supported platforms] [package links] [mailing list] [HyperNews] [FAQ] [computing help] [MINOS glossary] [archives]

Maintaining code with multiple compilers



( [main msrt page] | [help output] | [msrt and your test releases] | [SRT_CXX] | [msrt and multiple compilers] | [msrt and parallel builds] )



Minos offline software can be built with any compiler collection you want, as long as it is GCC.

Intro

You can use msrt along with standard SRT idioms to maintain multiple software builds, each with a different version of GCC. To do this a little setup is needed. All but the last step shown below is independent of msrt.

First, you need to tell SRT where to find the actuall compilers. Probably the best (and most "official" way) to do this is to create an SRT_SITE directory in the release directory which holds SRT .mk files which override some of SRT's MAKE variables. Alternatively you can forget all about this SRT_SITE stuff and simply select the compiler by making sure it is found first in your PATH variable. For the rest of this doc, it is assumed to use the SRT_SITE redirection method.

You can either create this SRT_SITE subdirectory directly in the release directory, or you might want to put this into a local CVS repository and integrate it into SRT's package system. Doing the latter is described here.

After that is setup, you need to tell SRT to use a compiler other than the default. This is done by passing in extra things to srt_setup.

Of course, you must also rebuild any C++ 3rd party packages (C and FORTRAN ones should still work). You should do this before rebuilding MINOS code. Suggestions on how to manage this are given at the end.

Finally, if you are using msrt you must tell it to use your environment instead of its own.

Setting up SRT for multiple compilers

Follow these steps:
  1. Create SRT_MINOS in some CVS repository (not in MINOS CVS!).
    1. Create empty SRT_SITE at repository top level. Obviously change some_ values to something reasonable.
      cvs -d some_cvsroot import -m "Some comment" SRT_SITE some_name some_tag
      

    2. Check this out in to SRTs packages area:
      mkdir $SRT_DIST/packages/SRT_SITE
      cd $SRT_DIST/packages/SRT_SITE
      echo "some_cvsroot" > cvsroot        # needed by SRT later
      cvs -d `cat cvsroot` get -d HEAD SRT_SITE
      addpkg -p SRT_SITE HEAD
      
      You will now have an empty SRT_SITE package.

    3. Create a sub directory:
      cd $SRT_DIST/releases/development/SRT_SITE
      mkdir special
      cvs add special
      cd special
      mkdir compilers
      cvs add compilers
      cd compilers
      

      You should be in the compilers/ subdir for the next steps.

    4. Create the override files. Note, the executable names here are what Debian GCC packages use. On Debian, one or all can be installed at the same time and they are differentiated by the version being appended to the compiler name (ie gcc-3.1 is gcc v 3.1).

      Other systems may do it differently, however in general, as long as the correct compiler executable is called, everything else should work. If you are not on a Debian system but you still have multiple GCCs installed under their generic names, you can still differentiate them by giving the full paths to their executables.

      Anyways, here are the files for 3 of the GCCs currently available (egcs is not shown and left as an exercise for any dinosaurs out there):

      • GCC 2.95.x:
        cat <<EOF >GCC_2_95.mk
        CPP=g++-2.95
        CXX=g++-2.95
        GCC=gcc-2.95
        SHAREDAR=gcc-2.95
        EOF
        

      • GCC 3.0.x:
        cat <<EOF >GCC_3_0.mk
        CPP=g++-3.0
        CXX=g++-3.0
        GCC=gcc-3.0
        SHAREDAR=gcc-3.0
        EOF
        

      • GCC 3.1.x:
        cat <<EOF >GCC_3_1.mk
        CPP=g++-3.1
        CXX=g++-3.1
        GCC=gcc-3.1
        SHAREDAR=gcc-3.1
        EOF
        

    5. Commit it all
      cvs add GCC_2_95.mk GCC_3_0.mk GCC_3_1.mk
      cvs commit -m "some message" GCC_2_95.mk GCC_3_0.mk GCC_3_1.mk
      

  2. To select one of these use the SRT mechanism, eg:
    srt_setup SRT_CXX=GCC_3_1
    

  3. Test that things are okay:
    cd SRT_DIST/releases/development/Algorithm
    make MINOS_VERBOSE=yes -n all
    
    You should see the correct g++-3.1 being used.

  4. To use msrt in this scheme, you must do two things


Frozen release issues

Because the SRT_SITE package is not distributed in the setup/packages-RX.Y.Z file, you will need to add it by hand before creating a fully working frozen release. If you forget this, it will quietly use the default compiler! The steps to creating a frozen release is then:
	msrt release -r RX.Y.Z
	msrt update -r RX.Y.Z SRT_SITE
	msrt build -r RX.Y.Z

Additional/optional guidance:

Managing 3rd party packages compiled with multiple compilers

Here is one way to do it. It assumes each GCColection version differentiates itself by appending a version string to the executable name.

General environment setup

This configuration is done via the standard compiler variables (ie, CC). Write a setup script to be sourced that does something like (bash assumed, csh is left as an excersize):
my_basic_setup () {
    ver=$1
    if [ -z "$ver" ] ; then ver="2.95"; fi
        
    export CC=gcc-$ver
    export CXX=g++-$ver
    export CPP=cpp-$ver
    export F77=g77-$ver

    export ROOTSYS=/home/bviren/cvs/root/$CC
    PATH=$ROOTSYS/bin:$PATH
    export SIGC_DIR=/home/bviren/lib/sigc-1.1.11-$CC

    export LD_LIBRARY_PATH=$ROOTSYS/lib:$SIGC_DIR/lib:$LD_LIBRARY_PATH
}
my_srt_setup () {
    ver=$1
    if [ -z "$ver" ] ; then ver="GCC_2_95"; fi
    srt_setup SRT_CXX=$ver
}
my_setup () {
    version=$1
    if [ -z "$version" ] ; then version="3.1"
    my_basic_setup $version
    my_srt_setup GCC_`echo $gcc_ver | tr '.' '_'`
}
After sourceing, type
	bash> my_setup 3.1
Doing
	bash> env | egrep "CC|CXX|CPP|ROOTSYS|F77"
Should show various variables, all with the same version.

Note that this overrides some things normally set in the setup_minossoft files, so you should source this after sourcing the standard one.

Also note that in the case of SIGC_DIR, we are setting a compiler specific location. This must of course match where we installed it. See below for details.

ROOT

Building root for multiple compilers versions:
  1. Edit root/config/Makefile.<target> and comment out the definitions of the following: CXX CC F77

  2. Make sure these same compiler variables are correctly defined in your environment and that ROOTSYS points to a compiler specific directory (see above).

  3. Run you usual configure statement. Here is an example:
    ./configure linux \
    	--with-ttf-fontdir=/usr/share/fonts/truetype \
    	--with-ttf-incdir=/usr/include/freetype \
    	--with-xpm-libdir=/usr/X11R6/lib
    
  4. Make, install and test:
    make
    make install
    which root
    root
    

Libsigc++

Libsigc++ uses autoconf which knows about CC and other variables, so you just need to build it as normal once they have been defined. The only thing to do differently is to use the "--prefix" option in order to install it in a compiler specific directory. Eg:
./configure --prefix=/home/bviren/lib/sigc-1.1.11-gcc-3.1
This matches the setting above.

Last Modified: $Date: 2002/11/22 19:33:00 $
Contact: bv@bnl.gov
Page viewed from http://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/msrt-multi-compilers.html
Fermilab
Security, Privacy, Legal Fermi National Accelerator Laboratory