September 19: An exercise in EUPS: Building a customized MPICH2 lib using EUPS
or, "Rolling Your Own MPICH"
I'm working on a Linux64 system using Fedora Core 6. I've discovered that yum won't allow me to install g77 due to some known problems with 64-bit libraries. Unfortunately, when I try to do "eups_distrib --install --current -v -v mpich2" I get an erro in configure because g77 doesn't work.
At home, I use Gentoo Linux, which uses Portage - a system very similar in aims to EUPS, but very different in implementation and interface.
Normally, I would do something like this:
>emerge brokenpackage downloading brokenpackage-0.1.tar.gz unpacking brokenpackage-0.1. to PORTAGEDIR/brokenpackage/brokenpackage-0.1/files building brokenpackage-0.1... ... !!! ERROR: emerge brokenpackage-0.1 failed in src-compile >cp -r PORTAGEDIR/brokenpackage/brokenpackage-0.1/ PORTAGEOVERLAY/brokenpackage-0.1_rc1/ >cd PORTAGEOVERLAY/brokenpackage-0.1_rc1/ >mv brokenpackage-0.1.ebuild brokenpackage-0.1_rc1.ebuild > [edit .ebuild and/or untarred files, potentially running 'make,' 'configure,' or 'scons,' to see if everything builds cleanly] >ebuild-verify ./brokenpackage-0.1_rc1.ebuild [this tells portage that the files are up-to-date and not corrupted, thus do not need to be redownloaded] >[add brokenpackage-0.1_rc1 to local file for specifying site-specific package flags, marking it "stable"] > emerge ./brokenpackage-0.1_rc1.ebuild [if brokenpackage/files/ are not already compiled: "compiling brokenpackage-0.1_rc1"] installing brokenpackage-0.1_rc1... verifying... etc.. ... brokenpackage-0.1_rc1 installed. >
(personally, I really like this approach - after creating a usable .ebuild or patch for the source code, you just tell the maintainer and go on about your work, and if a newer version comes out, then if it builds happily [i.e., it addresses the problem you fixed], it will replace your hand-rolled one.)
However, this is EUPS, not Portage, so I need to do things the EUPS way.
First, I notice the following in the output of 'eups_distrib --help':
-r, --root arg Location of manifests and tarballs (may be a URL).
Default: $EUPS_PKGROOT
so I do 'echo $EUPS_PKGROOT' and see that the value is http://dev.lsstcorp.org/pkgs , so I point my browser there and get to here: http://dev.lsstcorp.org/pkgs/external/mpich2/1.0.5p4/
This directory contains an MPICH2 tarball and a ups table called 'mpich2.table'.
Great!
So I cd to my ~/lsstsandbox and wget the two files. Then I untar the mpich2 tarball and
mkdir mpich2-1.0.5p4/ups mv mpich2.table mpich2-1.0.5p4/ups cd mpich2-1.0.5p4 ./configure --disable-f77 && make
The building goes well (hooray!); now I just have to get EUPS to acknowledge this as a valid package.
[jmyers@mops64 lsstsandbox]$ setup -v -v -r mpich2-1.0.5p4 mpich2 1.0.5p4 WARNING: Using table file /home/jmyers/lsstsandbox/mpich2-1.0.5p4/ups/mpich2.table Setting up: mpich2 Flavor: Linux64 Version: 1.0.5p4
but
[jmyers@mops64 lsstsandbox]$ eups list | grep mpich
Hmm. Not really sure what that last command really did.
[jmyers@mops64 lsstsandbox]$ eups_declare -r mpich2-1.0.5p4 mpich2 1.0.5p4
WARNING : Not making PROD_DIR relative to any part of EUPS_PATH
mpich2-1.0.5p4 : /home/jmyers/lsstsandbox/ /usr/local/LSST
[jmyers@mops64 lsstsandbox]$ eups list | grep mpich
mpich2 1.0.5p4 Setup
[jmyers@mops64 lsstsandbox]$ eups_declare --current mpich2 1.0.5p4
[jmyers@mops64 lsstsandbox]$ eups list | grep mpich
mpich2 1.0.5p4 Current Setup
That looks good.
[jmyers@mops64 lsstsandbox]$ echo $LD_LIBRARY_PATH /usr/local/orbfit/lib:/opt/intel/fce/10.0.023/lib:/usr/local/auton/lib::/home/jmyers/lsstsandbox/mpich2/lib:/home/jmyers/lsstsandbox/mpich2/lib:/home/jmyers/lsstsandbox/mpich2/lib:/home/jmyers/lsstsandbox/mpich2-1.0.5p4/lib
Yep, that seems to have done it.
