Hi Tim, Eugene,
Actually, the part about not needing to run autogen.sh; if running
via a nightly/release tarball is not entirely accurate. The tarballs
are configured to allow parallel builds (e.g., "gmake -j6 ..."); however,
when you run autogen.sh when building in an older Lustre filesystem,
locking is not fully supported and so it disables the parallel builds.
The problem here is that the automake and the libtool builds are
interdependent, in a manner of speaking. The automake build installs
`aclocal` and your "new" automake references its own shared aclocal
tree. For example, I installed a newer automake for our OMPI builds
at NCCS and we have:
kmy@jaguarpf-login3:/sw/xt5/automake/1.10.1/sles10.1_pgi7.2.5> ls -dl
/sw/xt5/automake/1.10.1/sles10.1_pgi7.2.5/share/aclocal-1.10
drwxr-sr-x 2 kmy ccsstaff 8192 2009-02-04 16:20
/sw/xt5/automake/1.10.1/sles10.1_pgi7.2.5/share/aclocal-1.10
Sorry about the convoluted path, but that is another story. The point
is that by using my `automake`, you also get the attendant `aclocal`
and this `aclocal` will reference the above ".../share/aclocal-1.10"
directory for its macros.
This is the part where you get into trouble. The libtool install puts
a couple of files into the automake/aclocal shared directory, like so:
[kmy@odie ~] rpm -ql libtool-1.5.24-17 | grep aclocal
/usr/share/aclocal/libtool.m4
/usr/share/aclocal/ltdl.m4
/usr/share/libtool/libltdl/aclocal.m4
[kmy@odie ~]
This is why your `aclocal` clutches when it hits "AM_PROG_LIBTOOL".
There are other RPMs that do the same thing. So, if you want to install
a relocated automake (leave the default system automake in place), when
building the relocated automake, you must copy the default system macros
into your target shared aclocal directory before the install. For example:
# cp -p /usr/share/aclocal/*.m4 {...}/share/aclocal-1.10/
Then, do the automake install to update the macros that automake installs.
Installing a version of libtool to incorporate your version of automake
should work for the current issue. However, it is not a general solution,
because there are other macros that may be missing.
-- Ken
-----Original Message-----
From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf
Of Tim Mattox
Sent: Thursday, August 27, 2009 10:22 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] build problem, autogen
Hi Eugene,
That FAQ entry is correct.. except that soon we won't need a C++ compiler :-)
However, *IF* you want to run autogen.sh, you need recent
versions of all four gnu autotool dependencies:
m4, autoconf, automake, and libtool
as described here:
http://www.open-mpi.org/svn/building.php
However, if you are using a nightly tarball or a release
tarball, you should not need to (nor want to!) run autogen.sh,
and can just do the usual:
"./configure --pile-of-options; make; make install"
On Thu, Aug 27, 2009 at 9:45 PM, Eugene Loh<eugene....@sun.com> wrote:
> Tim Mattox wrote:
>
>> Don't forget to also install a recent gnu libtool.
>>
>
> Lemme see:
>
> http://www.open-mpi.org/faq/?category=building#build-tools says: "If you are
> building Open MPI from a tarball, you need a C compiler, a C++ compiler, and
> make... You do not need any special version of the GNU "Auto" tools
> (Autoconf, Automake, Libtool)."
>
> So, that presumably means I *should* be okay.
>
> For what it's worth, I can no longer find the places that led me to believe
> that:
>
> *) I needed the versions of the tools (m4, autoconf, automake) that I picked
> up.
> *) I did not need libtool since OMPI had its own, hacked up version.
>
> but those were the assumptions I operated under.
>
>> On Thursday, August 27, 2009, Jeff Squyres <jsquy...@cisco.com> wrote:
>>
>>>
>>> Don't you need a rehash in your script to make sure it picks up the
>>> newly-installed autotools?
>>>
>
> Good point. I'm a dummy about these things. Assuming I know how to fix
> what you're saying, I inserted a "rehash" in my script after "make install",
> but still got the same problem. That is, the relevent part of the script
> now says:
>
> foreach PACKAGE ( m4-1.4.13 autoconf-2.63 automake-1.10.2 )
> bunzip2 $PACKAGE.tar.bz2
> tar xf $PACKAGE.tar
> pushd $PACKAGE
> ./configure --prefix=$INSTALLDIR
> make
> make install
> popd
> rehash
> end
>
> bunzip2 openmpi-1.4a1r20984.tar.bz2
> tar xf openmpi-1.4a1r20984.tar
> pushd openmpi-1.4a1r20984
> ./autogen.sh
>
> and the end of the log file still says:
>
> *** Running GNU tools
> [Running] libtoolize --automake --copy
> [Running] aclocal
> configure.in:2123: warning: macro `AM_PROG_LIBTOOL' not found in library
> [Running] autoheader
> [Running] autoconf
> configure.in:2126: error: possibly undefined macro: AM_PROG_LIBTOOL
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
>
> -------------------------------------------------------------------------
> It seems that the execution of "autoconf" has failed. See above for
> the specific error message that caused it to abort.
> -------------------------------------------------------------------------
>
> Error running autogen.sh -l in romio. Aborting.
>
>>>
>>> On Aug 27, 2009, at 4:48 PM, Eugene Loh wrote:
>>>
>>>
>>> I'm having a build problem. I want to be able to build on all sorts of
>>> different machines and don't always know that the right versions of
>>> various tools will be available. So, I drag them around with me. So,
>>> e.g., I have these tarballs:
>>>
>>> autoconf-2.63.tar.bz2
>>> automake-1.10.2.tar.bz2
>>> m4-1.4.13.tar.bz2
>>> openmpi-1.4a1r20984.tar.bz2
>>>
>>> After building the other tools, I start autogen on OMPI and get this:
>>>
>>> *** Running GNU tools
>>> [Running] libtoolize --automake --copy
>>> [Running] aclocal
>>> http://configure.in:2123: warning: macro `AM_PROG_LIBTOOL' not found in
>>> library
>>> [Running] autoheader
>>> [Running] autoconf
>>> http://configure.in:2126: error: possibly undefined macro:
>>> AM_PROG_LIBTOOL
>>> If this token and others are legitimate, please use m4_pattern_allow.
>>> See the Autoconf documentation.
>>>
>>> -------------------------------------------------------------------------
>>> It seems that the execution of "autoconf" has failed. See above for
>>> the specific error message that caused it to abort.
>>> -------------------------------------------------------------------------
>>>
>>> Error running autogen.sh -l in romio. Aborting.
>>>
>>> What's up? This is SuSE with GCC. Run script and log file attached.
>>> Thanks for any help.
>>>
>>> #!/bin/csh -x
>>>
>>> ls
>>>
>>> setenv CFLAGS "-O -m64 -g"
>>> setenv CXXFLAGS "-O -m64 -g"
>>> setenv FFLAGS "-O -m64 -g"
>>> setenv FCFLAGS "-O -m64 -g"
>>>
>>> pwd
>>>
>>> set INSTALLDIR = `pwd`/myopt
>>> set path = ( $INSTALLDIR/bin /usr/ccs/bin /usr/bin /bin )
>>>
>>> foreach PACKAGE ( m4-1.4.13 autoconf-2.63 automake-1.10.2 )
>>> bunzip2 $PACKAGE.tar.bz2
>>> tar xf $PACKAGE.tar
>>> pushd $PACKAGE
>>> ./configure --prefix=$INSTALLDIR
>>> make
>>> make install
>>> popd
>>> end
>>>
>>> bunzip2 openmpi-1.4a1r20984.tar.bz2
>>> tar xf openmpi-1.4a1r20984.tar
>>> pushd openmpi-1.4a1r20984
>>> ./autogen.sh
>>> # ./configure \
>>> # --disable-visibility \
>>> # --enable-mpirun-prefix-by-default \
>>> # --prefix=$INSTALLDIR
>>> # make
>>> # make install
>>> popd
>>>
>>> ls
>>>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
--
Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
tmat...@gmail.com || timat...@open-mpi.org
I'm a bright... http://www.the-brights.net/
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
