February 2010 - Mpich2-core - mailman3.cels.anl.gov

rpath builds
by Pavan Balaji 01 Mar '10

01 Mar '10

It looks like MPICH2 is using -Wl,-rpath for shared library builds. This was reported as a problem by the Debian folks, so I removed it. However, I later realized that removing this means that when I do "mpiexec ./foo", the executable won't know where to pick the shared library from, unless it's in the default system or user path (i.e., listed in /etc/ld.so.conf or LD_LIBRARY_PATH). My testing didn't reveal this issue, since I had a system install of mpich2 that created /usr/lib/libmpich.so, and that was being used for the runs (which is even more dangerous than just failing). So, my question is, what should we do with this? Continue to use rpath as earlier? Or force everyone to have the lib directory in their library path, both while building MPICH2 and executing ; this is required while building MPICH2 for compiling the examples. http://trac.mcs.anl.gov/projects/mpich2/ticket/1012 -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

4 7

Re: [mpich2-core] rpath builds
by chan＠mcs.anl.gov 28 Feb '10

28 Feb '10

After -Wl,-rpath is disabled from mpich2's shared library support, would prepending LD_LIBRARY_PATH (or its equivalent) in mpich2 build system with $libdir(or $libbuild_dir) be able to get mpich2 to compile the examples ? A.Chan ----- "Pavan Balaji" <balaji(a)mcs.anl.gov> wrote: > It looks like MPICH2 is using -Wl,-rpath for shared library builds. > This > was reported as a problem by the Debian folks, so I removed it. > However, > I later realized that removing this means that when I do "mpiexec > ./foo", the executable won't know where to pick the shared library > from, > unless it's in the default system or user path (i.e., listed in > /etc/ld.so.conf or LD_LIBRARY_PATH). My testing didn't reveal this > issue, since I had a system install of mpich2 that created > /usr/lib/libmpich.so, and that was being used for the runs (which is > even more dangerous than just failing). > > So, my question is, what should we do with this? Continue to use > rpath > as earlier? Or force everyone to have the lib directory in their > library > path, both while building MPICH2 and executing ; this is required > while > building MPICH2 for compiling the examples. > > http://trac.mcs.anl.gov/projects/mpich2/ticket/1012 > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji

3 2

mpich2-1.2.1p1 tarball testing
by Dave Goodell 23 Feb '10

23 Feb '10

I've uploaded a candidate 1.2.1p1 tarball to SVN. You can grab it from SVN with svn export https://svn.mcs.anl.gov/repos/mpi/www/downlooads/tarballs/1.2.1p1/mpich2-1.… or from MCS machines out of my home directory: "/home/goodell/ mpich2-1.2.1p1.tar.gz" Please download it and sanity check it. Jayesh, will you start creating the Windows packages soon? -Dave

2 1

mpich2-1.3a1 release tomorrow
by Pavan Balaji 11 Feb '10

11 Feb '10

I'm planning to push out mpich2-1.3a1 tomorrow, assuming the nightly tests go through fine. Tomorrow, I'll also run some performance tests on SiCortex to make sure everything looks good (the machine is broken right now for some reason). -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

4 15

Re: [mpich2-core] maint/updatefiles + autotools
by chan＠mcs.anl.gov 11 Feb '10

11 Feb '10

FYI: The svn version of mpich2 as of now works with autotools being installed in different directories, this does not require the setting of ACLOCAL i.e. no patch required. (Checked on grind and surveyor). The likely reason as Dave said is because maint/updatefiles is already doing the magic of running libtoolize before every autoreconf. This is enabled through "ltdirs" in maint/updatefiles. Emptying "ltdirs" would stop some libtoolize from running that leads to hydra's autoreconf to fail for not able to find libtool m4 macros. Setting environment variable ACLOCAL to point to $LIBTOOL_HOME/share/aclocal solves the autoreconf problem. So there are multiple ways of solving the problem. Given some of us want to have the flexbility of autotools being installed in different directories and some wants to have a single autotools directory to minimize potential autotool failure. As Dave suggested, I am going to add a switch, -noatdircheck(and -no-atdir-check) to maint/updatefiles to disable the check of autotools being installed in different directories. A.Chan ----- "Pavan Balaji" <balaji(a)mcs.anl.gov> wrote: > Anthony, > > We didn't want to add this restriction either. But we already tried > and > couldn't get it working without this restriction. That's why we are > hesitant to go with something which is easier to use (we all agree to > that), but doesn't work reliably. > > It is very possible that we missed something earlier. So, if you can > get > it to work reliably, we are more than happy to go back to the older > model where different autotools can be different directories. > > In the meanwhile, here's the module script that I use, which is > likely > simpler: > > ======================================================================= > #! /bin/sh > > if test -z "$2" ; then > echo "Usage: $0 <module> <version>" > exit > fi > > (cd /homes/balaji/software/tools/$1-$2 && make install > /dev/null) > ======================================================================= > > Usage: > > % module autoconf 2.63 > > ... if you want to use autoconf-2.63. /homes/balaji/software/tools > has > different versions of autotools configured, all of them with the > prefix > /homes/balaji/software/tools/install. > > -- Pavan > > On 02/11/2010 10:35 AM, chan(a)mcs.anl.gov wrote: > > I'm happy to provide a patch if I've the time (My immediate > obligation > > is testing new ADLB on P and installing UPC with new driver on P), > so I > > will need to ask other who are willing to wait. Since I didn't > > bring automake (I don't even use automake anywhere) into mpich2, > > I would think that I would be much slower than you/Pavan in fixing > > the mpich2 build problem. (BTW, I am very surprised that automake > and > > libtool do NOT play nice together even after all these years. > > I was under the impression using automake and libtool together > would > > be very smooth). I think imposing a single directory requirement > for > > autotools for mpich2 is such a draconian measure that we should > avoid > > if possible, especially only few components in mpich2 uses > automake/libtool. > > Seems like there is lesson to be learnt here in this exercise. > > > > In terms of "module" problem, 2 issues there: 1) my past > > experience as part-time sysadm told me that it would be a mess to > > go down that route. I have a script similar to your zsh script > somewhere > > that built MPICH-1 and LAM with various compilers (+ different > versions). > > It is never as simple as just running the script in manging > multiplicity > > of combination. 2) Also, the "module" package that I use is a > simplified > > version of the real "module" and isn't really good at managing the > > complicated "module" environment. > > > > A.Chan > > > > ----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > > > >> On Feb 10, 2010, at 10:07 PM, chan(a)mcs.anl.gov wrote: > >> > >>> ----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > >>> > >>>> Running the script will generate the cartesian product > >>>> of all available software versions and put them in > >>>> "install/autotools-${ac_ver}_${am_ver}_${lt_ver}" and create a > >>>> corresponding module file > >>>> "install/autotools-${ac_ver}_${am_ver}_${lt_ver}.module". It > will > >>>> also create a log of the entire build process in "build.log". > >>> This is a horrible approach to go down. Just loading the module > >>> is difficult, "module add autotools-2.63_1.11_2.2.6b", which > >>> I don't know who can remember the name. But one can always make > a > >>> shorter name to represent the long string, that creates a naming > >> issue > >>> in the long run. It is the management of the multiplicity of the > >>> combination that scares me, a problem in the long run, plus > >>> the hidden dimension that autoconf works with only certain > >>> versions of m4. Since no one is interested in "module" here, I > will > >>> shut up by saying this is a path I would like to avoid unless I > >> have > >>> no other choice. > >> Like I said before, I'd like to see your patch, not just a sketch > of a > >> > >> solution. I spent plenty of time previously trying to debug/fix > this, > >> > >> and even more now discussing it, and IMO the single directory > >> restriction is the best way to deal with this for now. > >> > >> As for your distaste for my solution to your module problem, I'm > sure > >> > >> it could be improved. The module file for each autoconf/automake/ > > >> libtool package could remove the old "autotools-..." entry and add > an > >> > >> updated "autotools-..." entry when the module is unloaded/loaded. > > >> Names can be improved. Tab completion simplifies lots of things. > The > >> > >> main point I was trying to illustrate is that this is a tractable > > >> problem with a small amount of work on your end. > >> > >> -Dave > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich2-core] mpich2-1.3a1 release tomorrow
by jayesh＠mcs.anl.gov 11 Feb '10

11 Feb '10

Pavan, I just committed the windows installers for 1.3a1 release to svn. Please go ahead with checking-in the mpich2 tarball and the release announcement. -Jayesh ----- Original Message ----- From: "Pavan Balaji" <balaji(a)mcs.anl.gov> To: mpich2-core(a)mcs.anl.gov Sent: Thursday, February 11, 2010 11:30:40 AM GMT -06:00 US/Canada Central Subject: Re: [mpich2-core] mpich2-1.3a1 release tomorrow I already found a small bug in mpich2-1.3a1 :-). mpiexec -info doesn't report the CFLAGS, etc., correctly. But I don't think that's critical to fix for this release. The tarball is available here: http://www.mcs.anl.gov/research/projects/mpich2staging/balaji/mpich2/downlo… Please try it out. I'll send out the announcement this evening. Thanks, -- Pavan On 02/11/2010 09:16 AM, Pavan Balaji wrote: > Ok, the nightly tests look good. There's some failure for shm with Intel > compilers, but I'm planning to ignore that since this is only an alpha > (and I don't particularly like shm). > > If no one has any objections, I can tag mpich2-1.3a1 and create a tarball. > > -- Pavan > > On 02/10/2010 12:17 PM, Pavan Balaji wrote: >> On 02/10/2010 12:05 PM, Anthony Chan wrote: >>> Did you create a branch for the 1.3 release ? >>> i.e. Can I check in anything to svn ? >> There's no plan to create a branch for 1.3a1, so it's all on the trunk. >> Don't commit anything as yet (unless it's a critical bug fix). I'll send >> out another email once trunk is open for commits again. >> >> -- Pavan >> > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich2-core] maint/updatefiles + autotools
by chan＠mcs.anl.gov 11 Feb '10

11 Feb '10

I'm happy to provide a patch if I've the time (My immediate obligation is testing new ADLB on P and installing UPC with new driver on P), so I will need to ask other who are willing to wait. Since I didn't bring automake (I don't even use automake anywhere) into mpich2, I would think that I would be much slower than you/Pavan in fixing the mpich2 build problem. (BTW, I am very surprised that automake and libtool do NOT play nice together even after all these years. I was under the impression using automake and libtool together would be very smooth). I think imposing a single directory requirement for autotools for mpich2 is such a draconian measure that we should avoid if possible, especially only few components in mpich2 uses automake/libtool. Seems like there is lesson to be learnt here in this exercise. In terms of "module" problem, 2 issues there: 1) my past experience as part-time sysadm told me that it would be a mess to go down that route. I have a script similar to your zsh script somewhere that built MPICH-1 and LAM with various compilers (+ different versions). It is never as simple as just running the script in manging multiplicity of combination. 2) Also, the "module" package that I use is a simplified version of the real "module" and isn't really good at managing the complicated "module" environment. A.Chan ----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > On Feb 10, 2010, at 10:07 PM, chan(a)mcs.anl.gov wrote: > > > ----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > > > >> Running the script will generate the cartesian product > >> of all available software versions and put them in > >> "install/autotools-${ac_ver}_${am_ver}_${lt_ver}" and create a > >> corresponding module file > >> "install/autotools-${ac_ver}_${am_ver}_${lt_ver}.module". It will > >> also create a log of the entire build process in "build.log". > > > > This is a horrible approach to go down. Just loading the module > > is difficult, "module add autotools-2.63_1.11_2.2.6b", which > > I don't know who can remember the name. But one can always make a > > shorter name to represent the long string, that creates a naming > issue > > in the long run. It is the management of the multiplicity of the > > combination that scares me, a problem in the long run, plus > > the hidden dimension that autoconf works with only certain > > versions of m4. Since no one is interested in "module" here, I will > > shut up by saying this is a path I would like to avoid unless I > have > > no other choice. > > Like I said before, I'd like to see your patch, not just a sketch of a > > solution. I spent plenty of time previously trying to debug/fix this, > > and even more now discussing it, and IMO the single directory > restriction is the best way to deal with this for now. > > As for your distaste for my solution to your module problem, I'm sure > > it could be improved. The module file for each autoconf/automake/ > libtool package could remove the old "autotools-..." entry and add an > > updated "autotools-..." entry when the module is unloaded/loaded. > Names can be improved. Tab completion simplifies lots of things. The > > main point I was trying to illustrate is that this is a tractable > problem with a small amount of work on your end. > > -Dave

2 1

Re: [mpich2-core] maint/updatefiles + autotools
by chan＠mcs.anl.gov 11 Feb '10

11 Feb '10

----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > Running the script will generate the cartesian product > of all available software versions and put them in > "install/autotools-${ac_ver}_${am_ver}_${lt_ver}" and create a > corresponding module file > "install/autotools-${ac_ver}_${am_ver}_${lt_ver}.module". It will > also create a log of the entire build process in "build.log". This is a horrible approach to go down. Just loading the module is difficult, "module add autotools-2.63_1.11_2.2.6b", which I don't know who can remember the name. But one can always make a shorter name to represent the long string, that creates a naming issue in the long run. It is the management of the multiplicity of the combination that scares me, a problem in the long run, plus the hidden dimension that autoconf works with only certain versions of m4. Since no one is interested in "module" here, I will shut up by saying this is a path I would like to avoid unless I have no other choice. A.Chan

2 1

Re: [mpich2-core] maint/updatefiles + autotools
by chan＠mcs.anl.gov 10 Feb '10

10 Feb '10

Simpler yet. It appears that autoconf-2.63's autoreconf is broken, i.e. it does not accept -I. But autoconf-2.64 and 2.65's autoreconf accepts -I, i.e. no need to set ACLOCAL. Since automake said that aclocal could disappear eventually but not now, so we could set ACLOCAL for now till we upgrade to later autoconf.... A.Chan /homes/chan/ts_automake> echo $ACLOCAL ACLOCAL: Undefined variable. /homes/chan/ts_automake> rm -rf autom4te.cache ltmain.sh aclocal.m4 configure /homes/chan/ts_automake> ls -lt total 95 -rw-r--r-- 1 chan uother 37 2010-02-10 19:03 configure.ac -rwxr-xr-x 1 chan uother 46260 2010-02-10 16:52 config.guess* -rwxr-xr-x 1 chan uother 33952 2010-02-10 16:52 config.sub* -rwxr-xr-x 1 chan uother 13663 2010-02-10 16:51 install-sh* /homes/chan/ts_automake> autoreconf -ivf -I $LIBTOOL_HOME/share/aclocal autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /homes/chan/libtool/2.2.6/share/aclocal --force autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoreconf: running: /homes/chan/autoconf/2.64/bin/autoconf --include=/homes/chan/libtool/2.2.6/share/aclocal --force autoreconf: configure.ac: not using Autoheader autoreconf: configure.ac: not using Automake autoreconf: Leaving directory `.' ----- chan(a)mcs.anl.gov wrote: > Don't think I can provide a patch since I don't understand > how OPA and PLPA works with the rest of mpich2. > > The following may be what you are looking for, setting the > environment variable ACLOCAL that gets aclocal to search > libtool's share/aclocal seems to do the trick. > > I created a simple configure.ac > > /homes/chan/ts_automake> ls -lt > total 95 > -rwxr-xr-x 1 chan uother 46260 2010-02-10 16:52 config.guess* > -rwxr-xr-x 1 chan uother 33952 2010-02-10 16:52 config.sub* > -rwxr-xr-x 1 chan uother 13663 2010-02-10 16:51 install-sh* > -rw-r--r-- 1 chan uother 37 2010-02-10 16:37 configure.ac > > /homes/chan/ts_automake> cat configure.ac > AC_INIT() > AC_PROG_LIBTOOL > AC_OUTPUT > > I then loaded the modules for automake,autoconf and libtool > which are installed in different locations and do "autoreconf -ivf" > > /homes/chan/ts_automake> module add automake autoconf libtool > /homes/chan/ts_automake> autoreconf -ivf > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal --force > autoreconf: configure.ac: tracing > autoreconf: configure.ac: not using Libtool > autoreconf: running: /homes/chan/autoconf/2.63/bin/autoconf --force > configure.ac:2: error: possibly undefined macro: AC_PROG_LIBTOOL > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /homes/chan/autoconf/2.63/bin/autoconf failed with exit > status: 1 > > I think this is the error that you mentioned since it > as a "not using Libtool" message. I then define > the environment variable > > ACLOCAL="$AUTOMAKE_HOME/bin/aclocal -I $LIBTOOL_HOME/share/aclocal" > > which in my case becomes > /homes/chan/ts_automake> echo $ACLOCAL > /homes/chan/automake/1.11/bin/aclocal -I > /homes/chan/libtool/2.2.6/share/aclocal > > Then I rerun "autoconf -ivf" > /homes/chan/ts_automake> autoreconf -ivf > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: /homes/chan/automake/1.11/bin/aclocal -I > /homes/chan/libtool/2.2.6/share/aclocal --force > autoreconf: configure.ac: tracing > autoreconf: running: libtoolize --copy --force > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to > configure.ac and > libtoolize: rerunning libtoolize, to keep the correct libtool macros > in-tree. > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. > autoreconf: running: /homes/chan/autoconf/2.63/bin/autoconf --force > autoreconf: configure.ac: not using Autoheader > autoreconf: configure.ac: not using Automake > autoreconf: Leaving directory `.' > > The configure generated seems to be working fine. > > A.Chan > > ----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > > > On Feb 10, 2010, at 2:57 PM, chan(a)mcs.anl.gov wrote: > > > > > I am still thinking in "module" mode so I can swap out > > > one set of autotools to another one. The same directory > > > requirement will require me to install > > > autoconf-2.63+libtool-2.2.6b+automake-1.11.1 in one directory, > > > autoconf-2.64+libtool-2.2.6b+automake-1.11.1 in another directory, > > > autoconf-2.65+..... > > > When newer automake or libtool is released, all 3 sets will need > > > to be reinstalled.... > > > > > > I SINCERELY hope that the single autotools directory won't be a > > > requirement in mpich2's build system. > > > > Then I SINCERELY hope that you provide a patch to the build system > > that solves all the various autotools path problems in a reliable > > fashion. Until then, this is the most straightforward way to avoid > > problems. > > > > Your module system isn't too hard to fix with some scripting. I've > > attached a zsh script that should pretty much just take care of > > everything. You'll need to change the module file output at the end > > > > as appropriate because I don't know how to write module files and > I'm > > > > not particularly interested in learning. Other than that you just > > need to create a few directories and download/un-tar the software > > versions that you care about (see the top of the script for > > instructions). Running the script will generate the cartesian > product > > > > of all available software versions and put them in > > "install/autotools-$ > > {ac_ver}_${am_ver}_${lt_ver}" and create a corresponding module file > > > > "install/autotools-${ac_ver}_${am_ver}_${lt_ver}.module". It will > > also create a log of the entire build process in "build.log". > > > > If you don't like the dependency on zsh, the translation to bash, > > tcsh, or traditional Bourne shell should be pretty straightforward. > I > > > > cobbled this together in 15 minutes and didn't want to hassle with > > writing the most portable Bourne shell script possible. > > > > -Dave

1 0

Re: [mpich2-core] maint/updatefiles + autotools
by chan＠mcs.anl.gov 10 Feb '10

10 Feb '10

Don't think I can provide a patch since I don't understand how OPA and PLPA works with the rest of mpich2. The following may be what you are looking for, setting the environment variable ACLOCAL that gets aclocal to search libtool's share/aclocal seems to do the trick. I created a simple configure.ac /homes/chan/ts_automake> ls -lt total 95 -rwxr-xr-x 1 chan uother 46260 2010-02-10 16:52 config.guess* -rwxr-xr-x 1 chan uother 33952 2010-02-10 16:52 config.sub* -rwxr-xr-x 1 chan uother 13663 2010-02-10 16:51 install-sh* -rw-r--r-- 1 chan uother 37 2010-02-10 16:37 configure.ac /homes/chan/ts_automake> cat configure.ac AC_INIT() AC_PROG_LIBTOOL AC_OUTPUT I then loaded the modules for automake,autoconf and libtool which are installed in different locations and do "autoreconf -ivf" /homes/chan/ts_automake> module add automake autoconf libtool /homes/chan/ts_automake> autoreconf -ivf autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /homes/chan/autoconf/2.63/bin/autoconf --force configure.ac:2: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /homes/chan/autoconf/2.63/bin/autoconf failed with exit status: 1 I think this is the error that you mentioned since it as a "not using Libtool" message. I then define the environment variable ACLOCAL="$AUTOMAKE_HOME/bin/aclocal -I $LIBTOOL_HOME/share/aclocal" which in my case becomes /homes/chan/ts_automake> echo $ACLOCAL /homes/chan/automake/1.11/bin/aclocal -I /homes/chan/libtool/2.2.6/share/aclocal Then I rerun "autoconf -ivf" /homes/chan/ts_automake> autoreconf -ivf autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: /homes/chan/automake/1.11/bin/aclocal -I /homes/chan/libtool/2.2.6/share/aclocal --force autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoreconf: running: /homes/chan/autoconf/2.63/bin/autoconf --force autoreconf: configure.ac: not using Autoheader autoreconf: configure.ac: not using Automake autoreconf: Leaving directory `.' The configure generated seems to be working fine. A.Chan ----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > On Feb 10, 2010, at 2:57 PM, chan(a)mcs.anl.gov wrote: > > > I am still thinking in "module" mode so I can swap out > > one set of autotools to another one. The same directory > > requirement will require me to install > > autoconf-2.63+libtool-2.2.6b+automake-1.11.1 in one directory, > > autoconf-2.64+libtool-2.2.6b+automake-1.11.1 in another directory, > > autoconf-2.65+..... > > When newer automake or libtool is released, all 3 sets will need > > to be reinstalled.... > > > > I SINCERELY hope that the single autotools directory won't be a > > requirement in mpich2's build system. > > Then I SINCERELY hope that you provide a patch to the build system > that solves all the various autotools path problems in a reliable > fashion. Until then, this is the most straightforward way to avoid > problems. > > Your module system isn't too hard to fix with some scripting. I've > attached a zsh script that should pretty much just take care of > everything. You'll need to change the module file output at the end > > as appropriate because I don't know how to write module files and I'm > > not particularly interested in learning. Other than that you just > need to create a few directories and download/un-tar the software > versions that you care about (see the top of the script for > instructions). Running the script will generate the cartesian product > > of all available software versions and put them in > "install/autotools-$ > {ac_ver}_${am_ver}_${lt_ver}" and create a corresponding module file > > "install/autotools-${ac_ver}_${am_ver}_${lt_ver}.module". It will > also create a log of the entire build process in "build.log". > > If you don't like the dependency on zsh, the translation to bash, > tcsh, or traditional Bourne shell should be pretty straightforward. I > > cobbled this together in 15 minutes and didn't want to hassle with > writing the most portable Bourne shell script possible. > > -Dave

1 0