Re: [mpich2-core] maint/updatefiles + autotools
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 `.' ----- [email protected] 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" <[email protected]> wrote:
On Feb 10, 2010, at 2:57 PM, [email protected] 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
participants (1)
-
chan@mcs.anl.gov