In THCA4, mpga and mtl_common libraries were removed and I think functionality got included in vapi and mosal libs. We don't have to treat as an error if mpga and mtl_common libs doesn't exist but we can treat as warning and whoever is tyring to configure they need to go and verify whether mpga and mtl_common libs should be included or not. Thanks -Sridhar
________________________________ From: devel-boun...@open-mpi.org on behalf of Jeff Squyres Sent: Mon 8/8/2005 7:53 PM To: Open MPI Developers Subject: Re: [O-MPI devel] Fwd: Regarding MVAPI Component in Open MPI The README there was just copied over from the beta branch, and there is no mVAPI or Open IB support on the beta branch (the docs usually lag the code base -- they'll get a thorough scrubbing before the formal release). As we talked about on the teleconference (I confess to not remembering if you were on it or not), Open MPI supports both mVAPI and Open IB. I'll go update some of the obvious errors (like this one). As for lmpga and lmtl_common, ok, I'll modify the configure scripts as appropriate. I'm assuming that you're telling me that these two libraries are optional...? I.e., if we find them, we should use them? But if not, it's not an error...? Is that correct? (I don't know what the purpose of these libraries are) On Aug 8, 2005, at 4:58 AM, Sridhar Chirravuri wrote: > > Hi, > > I have got the latest code drop and this time I didn't give -r option > to svn co. The last line that it showed me is given below. > > Checked out revision 6760. > > > I am trying to install/configure/build OpenMPI on RHEL3 update 4 > machine. For this release, we don't have lmpga and lmtl_common > libraries. We are not using separate VAPI libraries. We only use lvapi > and lmosal. We do have lmpga and lmtl_common libs but with the older > release. > > In the file README of latest check out, I could see the following lin > > - Support for Quadrics and Infiniband (both mVAPI and OpenIB) is > > missing (see the current code base). > > What does it mean? Does OpenMPI has support for Infiniband (mVAPI)? I > am not getting why btl mVAPI component is not being built (in my > previous mail with ompi_info output). Could you please let me know > whether OpenMPI has got support for Infiniband (mVAPI)? If yes, what > sort of configuration options that I need to give? Or Do I have to > modify anything in the respective directories? Please let me know. > > Thanks > > -Sridhar > > > -----Original Message----- > From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] > On Behalf Of Jeff Squyres > Sent: Friday, August 05, 2005 6:15 PM > To: Open MPI Developers > Subject: Re: [O-MPI devel] Fwd: Regarding MVAPI Component in Open MPI > > On Aug 5, 2005, at 8:02 AM, Sridhar Chirravuri ((schirrav)) wrote: > > > Here is the output of ompi_info > > > > > > [root@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 > > Good. > > > 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 http://svn.open-mpi.org/svn/ompi/trunk 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 > > here: http://svnbook.red-bean.com/). > > 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 > > 6658). > > 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 http://svn.open-mpi.org/svn/ompi/trunk 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 autogen.sh. > > See the HACKING document for details on this (you don't need to run > > autogen.sh 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 > > information). > > > 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 autogen.sh. > > If you modify a .m4 file, you need to run autogen.sh again. > > autogen.sh 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 autogen.sh. > > 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 autogen.sh should do the Right Things for you. > > -- > > {+} Jeff Squyres > > {+} The Open MPI Project > > {+} http://www.open-mpi.org/ > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- {+} Jeff Squyres {+} The Open MPI Project {+} http://www.open-mpi.org/ _______________________________________________ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
<<winmail.dat>>
