Re: [OMPI devel] libevent socket code
When building statically on Cielito I see the following warnings: /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(session_dir.o): In function `orte_session_dir_get_name': session_dir.c:(.text+0x204): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In function `test_for_getaddrinfo_hacks': evutil.c:(.text+0x7a): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In function `evutil_unparse_protoname': evutil.c:(.text+0x7a): warning: Using 'getprotobynumber' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(if.o): In function `opal_ifaddrtoname': if.c:(.text+0x37c): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Two of those warnings are coming from libevent functions we do not use (and probably never will). The other two may be a little trickier to fix. -Nathan Excuse the terribly reply format. OWA sucks. From: devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] on behalf of Ralph Castain [r...@open-mpi.org] Sent: Monday, April 30, 2012 2:55 PM To: Open MPI Developers Subject: Re: [OMPI devel] libevent socket code Can you send me a copy of the warnings, or tell me which machine at LANL is generating them? I'm working on libevent now (found a bug they are helping with) and can take a look at it. On Apr 25, 2012, at 11:05 AM, Nathan Hjelm wrote: > Let me take a look. The code in question is in evutil.c and > bufferevent_sock.c . If there is no option we might be able to get away with > just removing these files from the Makefile.am. > > -Nathan > > On Wed, 25 Apr 2012, Jeff Squyres wrote: > >> On Apr 25, 2012, at 12:50 PM, Ralph Castain wrote: >> >>> Can't it be done with configuring --without-libevent-sockets or some such >>> thing? I really hate munging the code directly as it creates lots of >>> support issues and makes it harder to upgrade. >> >> If there's a libevent configure option we should be using, we can probably >> set that to be enabled by default. Let me know. >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> ___ >> 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 ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] libevent socket code
Is there a libevent configure switch we can use to disable those unused libevent functions? On Apr 30, 2012, at 11:49 PM, Hjelm, Nathan T wrote: > When building statically on Cielito I see the following warnings: > /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(session_dir.o): In > function `orte_session_dir_get_name': > session_dir.c:(.text+0x204): warning: Using 'getpwuid' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In function > `test_for_getaddrinfo_hacks': > evutil.c:(.text+0x7a): warning: Using 'getaddrinfo' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In function > `evutil_unparse_protoname': > evutil.c:(.text+0x7a): warning: Using 'getprotobynumber' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(if.o): In function > `opal_ifaddrtoname': > if.c:(.text+0x37c): warning: Using 'gethostbyname' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > > > Two of those warnings are coming from libevent functions we do not use (and > probably never will). The other two may be a little trickier to fix. > > -Nathan > > Excuse the terribly reply format. OWA sucks. > > From: devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] on behalf of > Ralph Castain [r...@open-mpi.org] > Sent: Monday, April 30, 2012 2:55 PM > To: Open MPI Developers > Subject: Re: [OMPI devel] libevent socket code > > Can you send me a copy of the warnings, or tell me which machine at LANL is > generating them? I'm working on libevent now (found a bug they are helping > with) and can take a look at it. > > > On Apr 25, 2012, at 11:05 AM, Nathan Hjelm wrote: > >> Let me take a look. The code in question is in evutil.c and >> bufferevent_sock.c . If there is no option we might be able to get away with >> just removing these files from the Makefile.am. >> >> -Nathan >> >> On Wed, 25 Apr 2012, Jeff Squyres wrote: >> >>> On Apr 25, 2012, at 12:50 PM, Ralph Castain wrote: >>> Can't it be done with configuring --without-libevent-sockets or some such thing? I really hate munging the code directly as it creates lots of support issues and makes it harder to upgrade. >>> >>> If there's a libevent configure option we should be using, we can probably >>> set that to be enabled by default. Let me know. >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> ___ >>> 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 > > > ___ > 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 jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] libevent socket code
I looked and the answer is "no". I could add one and push it upstream, but the problem is really due to someone not installing one or more static libraries. It looks like we are only finding the shared library versions of a couple of libs. I'm going to explore a little more and possibly request that someone fix it on the cluster. On May 1, 2012, at 7:29 AM, Jeff Squyres wrote: > Is there a libevent configure switch we can use to disable those unused > libevent functions? > > On Apr 30, 2012, at 11:49 PM, Hjelm, Nathan T wrote: > >> When building statically on Cielito I see the following warnings: >> /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(session_dir.o): In >> function `orte_session_dir_get_name': >> session_dir.c:(.text+0x204): warning: Using 'getpwuid' in statically linked >> applications requires at runtime the shared libraries from the glibc version >> used for linking >> /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In function >> `test_for_getaddrinfo_hacks': >> evutil.c:(.text+0x7a): warning: Using 'getaddrinfo' in statically linked >> applications requires at runtime the shared libraries from the glibc version >> used for linking >> /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In function >> `evutil_unparse_protoname': >> evutil.c:(.text+0x7a): warning: Using 'getprotobynumber' in statically >> linked applications requires at runtime the shared libraries from the glibc >> version used for linking >> /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(if.o): In function >> `opal_ifaddrtoname': >> if.c:(.text+0x37c): warning: Using 'gethostbyname' in statically linked >> applications requires at runtime the shared libraries from the glibc version >> used for linking >> >> >> Two of those warnings are coming from libevent functions we do not use (and >> probably never will). The other two may be a little trickier to fix. >> >> -Nathan >> >> Excuse the terribly reply format. OWA sucks. >> >> From: devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] on behalf of >> Ralph Castain [r...@open-mpi.org] >> Sent: Monday, April 30, 2012 2:55 PM >> To: Open MPI Developers >> Subject: Re: [OMPI devel] libevent socket code >> >> Can you send me a copy of the warnings, or tell me which machine at LANL is >> generating them? I'm working on libevent now (found a bug they are helping >> with) and can take a look at it. >> >> >> On Apr 25, 2012, at 11:05 AM, Nathan Hjelm wrote: >> >>> Let me take a look. The code in question is in evutil.c and >>> bufferevent_sock.c . If there is no option we might be able to get away >>> with just removing these files from the Makefile.am. >>> >>> -Nathan >>> >>> On Wed, 25 Apr 2012, Jeff Squyres wrote: >>> On Apr 25, 2012, at 12:50 PM, Ralph Castain wrote: > Can't it be done with configuring --without-libevent-sockets or some such > thing? I really hate munging the code directly as it creates lots of > support issues and makes it harder to upgrade. If there's a libevent configure option we should be using, we can probably set that to be enabled by default. Let me know. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ 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 >> >> >> ___ >> 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 > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] RFC: Update libevent
WHAT: Update libevent to 2.0.19 release WHEN: As soon as it is released, expected around May 11 WHY: The 2.0.19 release contains a critical fix to a bug I recently discovered in the libevent 2.0.x series Details: I discovered a bug in libevent over the last few days that causes it to unexpectedly "invert" event priorities. It is a slightly subtle bug, but we were able to provide a simple reproducer and so the libevent folks were able to quickly implement a fix. Stated simply, if you were in an event of a given priority and activated an event of higher priority, that new event would not get serviced if any event of the current priority were to become active prior to leaving the current event. In other words, libevent would service all active events of the current priority before even looking to see if a higher priority event was active. The patch adds the following logic to event_active: >IF AND >IF base> EQ AND >IF LT THEN > Thus, a rescan only occurs if a higher priority event becomes active during an event of lower priority. Unfortunately, ORTE relies on this behavior to handle errors - without the change, an error reported in a message from a daemon (for example) cannot be serviced until ALL messages that arrive during the processing of the message have been handled. In the case of a large cluster that is receiving a long list of messages, this prevents the error from being handled for quite some time.
Re: [OMPI devel] libevent socket code
Not that I can find. -Nathan From: devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] on behalf of Jeff Squyres [jsquy...@cisco.com] Sent: Tuesday, May 01, 2012 7:29 AM To: Open MPI Developers Subject: Re: [OMPI devel] libevent socket code Is there a libevent configure switch we can use to disable those unused libevent functions? On Apr 30, 2012, at 11:49 PM, Hjelm, Nathan T wrote: > When building statically on Cielito I see the following warnings: > /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(session_dir.o): In > function `orte_session_dir_get_name': > session_dir.c:(.text+0x204): warning: Using 'getpwuid' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In function > `test_for_getaddrinfo_hacks': > evutil.c:(.text+0x7a): warning: Using 'getaddrinfo' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In function > `evutil_unparse_protoname': > evutil.c:(.text+0x7a): warning: Using 'getprotobynumber' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(if.o): In function > `opal_ifaddrtoname': > if.c:(.text+0x37c): warning: Using 'gethostbyname' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > > > Two of those warnings are coming from libevent functions we do not use (and > probably never will). The other two may be a little trickier to fix. > > -Nathan > > Excuse the terribly reply format. OWA sucks. > > From: devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] on behalf of > Ralph Castain [r...@open-mpi.org] > Sent: Monday, April 30, 2012 2:55 PM > To: Open MPI Developers > Subject: Re: [OMPI devel] libevent socket code > > Can you send me a copy of the warnings, or tell me which machine at LANL is > generating them? I'm working on libevent now (found a bug they are helping > with) and can take a look at it. > > > On Apr 25, 2012, at 11:05 AM, Nathan Hjelm wrote: > >> Let me take a look. The code in question is in evutil.c and >> bufferevent_sock.c . If there is no option we might be able to get away with >> just removing these files from the Makefile.am. >> >> -Nathan >> >> On Wed, 25 Apr 2012, Jeff Squyres wrote: >> >>> On Apr 25, 2012, at 12:50 PM, Ralph Castain wrote: >>> Can't it be done with configuring --without-libevent-sockets or some such thing? I really hate munging the code directly as it creates lots of support issues and makes it harder to upgrade. >>> >>> If there's a libevent configure option we should be using, we can probably >>> set that to be enabled by default. Let me know. >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> ___ >>> 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 > > > ___ > 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 jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] Potential ob1 bug
Ran across a problem in a failure path of start_prepare in ob1. If prepare_src
succeed but send fails the send request convertor needs to be rolled back to
the correct position. Can someone with more knowledge of ob1 check if this is
indeed an error. Patch is below.
-Nathan
diff --git a/ompi/mca/pml/ob1/pml_ob1_sendreq.c
b/ompi/mca/pml/ob1/pml_ob1_sendreq.c
index 2a8ac03..5505918 100644
--- a/ompi/mca/pml/ob1/pml_ob1_sendreq.c
+++ b/ompi/mca/pml/ob1/pml_ob1_sendreq.c
@@ -570,6 +570,7 @@ int mca_pml_ob1_send_request_start_prepare(
mca_pml_ob1_send_request_t* sendreq,
mca_bml_base_btl_t* bml_btl,
size_t size )
{
+size_t old_position = sendreq->req_send.req_base.req_convertor.bConverted;
mca_btl_base_descriptor_t* des;
mca_btl_base_segment_t* segment;
mca_pml_ob1_hdr_t* hdr;
@@ -614,6 +615,9 @@ int mca_pml_ob1_send_request_start_prepare(
mca_pml_ob1_send_request_t* sendreq,
return OMPI_SUCCESS;
}
mca_bml_base_free(bml_btl, des );
+
+opal_convertor_set_position(&sendreq->req_send.req_base.req_convertor,
+&old_position);
return rc;
}
Re: [OMPI devel] [EXTERNAL] Re: libevent socket code
This isn't a static library problem and it can't be fixed by the cluster admins, it's a glibc design problem. There are a set of functions (those that use the services configured with nsswitch.conf, which includes host name resolution and user information resolution) that are implemented through a set of modules which are dlopened. There are four or five solutions to the problem, none good, including: - Don't use functions which cause the warning - Don't use glibc - Don't try to statically link - Create a dynamically linked "proxy app" for those functions - Make sure that glibc is installed on the compute machines, so that the runtime libraries are available, and ignore the warnings (things will work correctly in this mode) Personally, I like option 3. There's really no reason to statically link glibc into your executable. It should already be staged on the compute node if the machine admin knows what he's doing. Brian On 5/1/12 8:20 AM, "Ralph Castain" wrote: >I looked and the answer is "no". I could add one and push it upstream, >but the problem is really due to someone not installing one or more >static libraries. It looks like we are only finding the shared library >versions of a couple of libs. I'm going to explore a little more and >possibly request that someone fix it on the cluster. > > >On May 1, 2012, at 7:29 AM, Jeff Squyres wrote: > >> Is there a libevent configure switch we can use to disable those unused >>libevent functions? >> >> On Apr 30, 2012, at 11:49 PM, Hjelm, Nathan T wrote: >> >>> When building statically on Cielito I see the following warnings: >>> /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(session_dir.o): In >>>function `orte_session_dir_get_name': >>> session_dir.c:(.text+0x204): warning: Using 'getpwuid' in statically >>>linked applications requires at runtime the shared libraries from the >>>glibc version used for linking >>> /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In >>>function `test_for_getaddrinfo_hacks': >>> evutil.c:(.text+0x7a): warning: Using 'getaddrinfo' in statically >>>linked applications requires at runtime the shared libraries from the >>>glibc version used for linking >>> /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(evutil.o): In >>>function `evutil_unparse_protoname': >>> evutil.c:(.text+0x7a): warning: Using 'getprotobynumber' in statically >>>linked applications requires at runtime the shared libraries from the >>>glibc version used for linking >>> /scratch/hjelmn/xe6/openmpi-gcc/trunk/lib/libmpi.a(if.o): In function >>>`opal_ifaddrtoname': >>> if.c:(.text+0x37c): warning: Using 'gethostbyname' in statically >>>linked applications requires at runtime the shared libraries from the >>>glibc version used for linking >>> >>> >>> Two of those warnings are coming from libevent functions we do not use >>>(and probably never will). The other two may be a little trickier to >>>fix. >>> >>> -Nathan >>> >>> Excuse the terribly reply format. OWA sucks. >>> >>> From: devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] on >>>behalf of Ralph Castain [r...@open-mpi.org] >>> Sent: Monday, April 30, 2012 2:55 PM >>> To: Open MPI Developers >>> Subject: Re: [OMPI devel] libevent socket code >>> >>> Can you send me a copy of the warnings, or tell me which machine at >>>LANL is generating them? I'm working on libevent now (found a bug they >>>are helping with) and can take a look at it. >>> >>> >>> On Apr 25, 2012, at 11:05 AM, Nathan Hjelm wrote: >>> Let me take a look. The code in question is in evutil.c and bufferevent_sock.c . If there is no option we might be able to get away with just removing these files from the Makefile.am. -Nathan On Wed, 25 Apr 2012, Jeff Squyres wrote: > On Apr 25, 2012, at 12:50 PM, Ralph Castain wrote: > >> Can't it be done with configuring --without-libevent-sockets or >>some such thing? I really hate munging the code directly as it >>creates lots of support issues and makes it harder to upgrade. > > If there's a libevent configure option we should be using, we can >probably set that to be enabled by default. Let me know. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > 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 >>> >>> >>> ___ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >>> ___ >>> devel mailing list >>> de..
[OMPI devel] RFC: Upgrade trunk to AC 2.69
WHAT: Upgrade the SVN trunk Autoconf requirement to AC 2.69 (just released last week) WHY: Some of our Fortran configury is now officially supported WHERE: ompi/config/*.m4 TIMEOUT: Teleconf, Tuesday 8 May 2012 - More detail: Some of the configury that we have written in our own m4 is now officially supported by Autoconf 2.69. Specifically, there's some new Fortran AC macros in 2.69 that do some of the things that we are doing by hand in m4. It would be nice to get rid of our own m4 and replace it with officially-supported Autoconf m4 macros. This is a *developer only* issue, meaning that users who just "./configure && make install" won't be affected. But all developers will need to upgrade to AC 2.69 -- autogen.pl will fail otherwise. The main issue driving the timing here is that the Fortran stuff is still fresh in my brain. We certainly could defer the switch indefinitely, but the longer this later, the more stale all this new fortran stuff will get in my head (i.e., we'll keep using our own kludgey m4). -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI devel] 1.6.x compilation failure with intel compiler
Hi, ompi 1.6.x - compilation fails with intel compiler, but works with gcc. compiler version: 10.1.026 Regards CXX otfaux.o CXX Control.o CXX Handler.o CXX State.o CXXLD otfaux ../../otflib/.libs/libotf.so: undefined reference to `inflateReset' ../../otflib/.libs/libotf.so: undefined reference to `inflateEnd' ../../otflib/.libs/libotf.so: undefined reference to `deflate' ../../otflib/.libs/libotf.so: undefined reference to `deflateInit_' ../../otflib/.libs/libotf.so: undefined reference to `inflate' ../../otflib/.libs/libotf.so: undefined reference to `inflateSync' ../../otflib/.libs/libotf.so: undefined reference to `deflateEnd' ../../otflib/.libs/libotf.so: undefined reference to `inflateInit_' make[9]: *** [otfaux] Error 1
Re: [OMPI devel] 1.6.x compilation failure with intel compiler
Can you please file a proper bug report? (background info, configure line, etc.) Thanks. On May 1, 2012, at 1:29 PM, Mike Dubman wrote: > > > > > > > Hi, > > > > ompi 1.6.x - compilation fails with intel compiler, but works with gcc. > > > > compiler version: > 10.1.026 > > > > Regards > > > > > > > CXXotfaux.o > CXXControl.o > CXXHandler.o > CXXState.o > CXXLD otfaux > ../../otflib/.libs/libotf.so: undefined reference to `inflateReset' > ../../otflib/.libs/libotf.so: undefined reference to `inflateEnd' > ../../otflib/.libs/libotf.so: undefined reference to `deflate' > ../../otflib/.libs/libotf.so: undefined reference to `deflateInit_' > ../../otflib/.libs/libotf.so: undefined reference to `inflate' > ../../otflib/.libs/libotf.so: undefined reference to `inflateSync' > ../../otflib/.libs/libotf.so: undefined reference to `deflateEnd' > ../../otflib/.libs/libotf.so: undefined reference to `inflateInit_' > make[9]: *** [otfaux] Error 1 > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
