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.

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2005-08-05 07:44:40

On Aug 5, 2005, at 8:02 AM, Sridhar Chirravuri ((schirrav)) wrote:

> Here is the output of ompi_info
> [root_at_micrompi-1 ompi]# ompi_info
>                 Open MPI: 1.0a1r6612M
>    Open MPI SVN revision: r6612M
> [snipped] 
> The OpenMPI version that I am using r6612 (I could see from the output
> ompi_info command). There is NO btl frame where as mpool was built.
> In the configure options, giving  --with-btl-mvapi=/opt/topspin would
> sufficient as it has got include and lib64 directories. Therefore it
> will pick up the necessary things. Also, I have set the following
> flags


> export CFLAGS="-I/optl/topspin/include -I/opt/topspin/include/vapi"
> export LDFLAGS="-lmosal -lvapi -L/opt/topspin/lib64"
> export btl_mvapi_LDFLAGS=$LDFLAGS
> export btl_mvapi_LIBS=$LDFLAGS

You shouldn't need these -- our configure script should figure all that
out with just the --with-btl-mvapi switch. Let us know if it doesn't
(an explicit goal of our configure script is to handle all this kind of
complexity and do all the Right Things with a single --with switch).

> I will configure and build the latest code. To get the latest code, I
> have run the following command. Please let me know if I am not
> correct.
> svn co -r6613 ompi

No -- do not specify the -r switch. That asks for a specific
repository r number, and 6613 only 1 commit beyond your last version.
The current r number at the HEAD is 6746, for example -- 6613 was
committed around 9am on July 27th. Specifically, the r number
represents a unique state of the *entire* repository. So every commit
increments the r number (more Subversion documentation is available

I believe that in 6612 and 6613, we still had many of the 3rd
generation BTL stuff .ompi_ignore'd out, so they would not have built
(many were removed at 6616, but even more were removed as late as

Note that the "M" in your version number means that you have locally
modified the tree -- so you started with r6612, but then made local
modifications (the configure script queries Subversion to see what
version your tree it; Subversion detects these kinds of things).

If you "svn co ompi" (i.e., do
not specify -r), it'll just get the latest number.

Alternatively, if you have a checkout already, you can just run "svn
up" within that tree and it will update to the latest (quite analogous
to "cvs up").

> Configured as..
> ./configure --prefix=/openmpi --with-btl-mvapi=/opt/topspin/

When you get a subversion checkout, you need to first run
See the HACKING document for details on this (you don't need to run in tarballs) and the README document for common building /
running. Both of these are in the top-level directory of the SVN
checkout (update to the latest to get the most up-to-date README

> When I gave make all, it is configuring again and again, I mean it is
> going in a loop. In my machine, I do not need libmpga and
> libmtl_common, hence I removed -lmpga and -lmtl_common entries from
> config/ompi_check_mvapi.m4 file and then ran

If you modify a .m4 file, you need to run again. is simply a wrapper around all the right GNU Auto tool
commands (autoconf, autoheader, libtool, automake, etc.) to setup all
the build scripts properly. However, automake also inserts
dependencies in makefiles such that if any of the dependent m4 files
change (for example), it should re-run the necessary commands. In
theory, that is supposed to work, but we've never really exercised that
-- we just re-run

But could you clarify -- why do you not need libmpga or libmtl_common?
Are these libraries from a different mVAPI implementation? I would
like to have our configure script do the Right Things regardless of
which mVAPI implementation is being used -- if we need to add a little
more logic to make this correct, then so be it.

> I don't have any clue why the configuration is going in loop even
> while building. I could see that config.status --recheck is being
> issued from Makefile and I feel this might the reason for configure to
> run in loop.

Running should do the Right Things for you.

{+} Jeff Squyres
{+} The Open MPI Project