Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] Fix for XLC + libtool issue
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-04-25 07:54:39

On Apr 25, 2008, at 7:40 AM, Ralf Wildenhues wrote:

>> We actually already have an outstanding ticket to upgrade to 2.2.2
>> ( ). We were following
>> the Libtool development process closely and
>> waiting for at least 2.2.2 (get past 2.2.0).
> 2.2.2 is out since April 1st, and has seen a number of fixes since.
> We
> hope to do 2.2.4 soon, but of course if you try it out before then any
> eventual remaining issues may be fixed before that.

Sorry -- I didn't mean to imply that we hadn't noticed that 2.2.2 had
been released. I was trying to say that LT 2.2.2 was our gating
factor and that has now been met. We have an outstanding ticket to
upgrade the automated process that builds the official OMPI tarballs
(we have a strictly controlled process that runs in a specific
environment to make official OMPI tarballs -- that's where the upgrade
needs to occur); it just hasn't happened yet. It's marked as a
blocker for the OMPI v1.3 release.

I have been using 2.2.2 on my development cluster since shortly after
it was released (I think other developers are, too).

>> Additionally, Ralf W. recomends to us that we should also upgrade
>> Autoconf to 2.62 or later. I've been loosely watching that process;
>> 2.62 requires a newer GNU m4 which we haven't yet decided if we want
>> to require.
> Yes you need GNU m4 1.4.5 or newer. m4 1.4.11 and Autoconf 2.62 speed
> up auto* and config.status run time, respectively. For the latter, we
> used OMPI as test bed application, see the first set of timings in:
> <>

Wow -- those timings are impressive! Quoting that URL (OMPI is [1]):

For example[1], in a large package with 871 substituted variables, of
which 2*136 are produced by AM_CONDITIONAL, and roughly 210 Makefiles.
'./config.status' execution for those Makefiles (no headers, no
- with Automake-1.9.6: 78.54user 9.32system 1:38.60elapsed 89%CPU
(0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major
+2551217minor)pagefaults 0swaps
- with Automake 1.10 (no superfluous $(*_TRUE)/$(*_FALSE) settings):
56.11user 8.31system 1:16.51elapsed 84%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (0major+2284709minor)pagefaults 0swaps
- additionally with the Autoconf patch below: 11.24user 3.62system
0:21.89elapsed 67%CPU (0avgtext+0avgdata 0maxresident)k 0inputs
+0outputs (0major+935332minor)pagefaults 0swaps

Is the "with the Autoconf patch below" equivalent to AM 1.10 + AC 2.62?

Jeff Squyres
Cisco Systems