Re: [OMPI devel] Autogen improvements: ready for blast off
We can build an SVN checkout, but with a tarball we get this: ... Undefined first referenced symbol in file opal_backtrace_print../../../opal/.libs/libopen-pal.so opal_backtrace_buffer ../../../opal/.libs/libopen-pal.so ld: fatal: Symbol referencing errors. No output written to .libs/opal_wrapper I suspect this is because the -G link lines for libopen-pal.so differ between the tarball and the SVN checkout. Specifically, this file is *not* included in the link line in the tarball case: mca/backtrace/printstack/.libs/libmca_backtrace_printstack.a I assume this means no backtrace plug-in is getting built in the tarball case for some reason? -Ethan On Sat, Sep/18/2010 09:57:44AM, Jeff Squyres wrote: > I made autogen.pl take care of removing stale generated-m4 files > automatically, so no one should need to manually rm any .m4 files. Just > running autogen.pl should be sufficient. Additionally, making nightly > tarballs was accidental collateral damage. I'm working on fixing this; I > think I'm pretty close. > > I updated the wiki pages last week with all you need to know about the > improvements to the build system: > > https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen > https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent > https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework > > If you make any new components or frameworks, I highly suggest you re-read > these pages. > > A note from a prior email is critically important for all developers: > > > > > *** THE MOST IMPORTANT THING DEVELOPERS NEED TO KNOW *** > > > > > > > > If your component has a configure.m4 file, it MUST call AC_CONFIG_FILES > > for your Makefile.am! (and/or any files that you want configure to > > generate). We converted all existing configure.m4 files -- the > > ompi/mca/btl/tcp/configure.m4 is a nice simple example to see what I > > mean. > > > > > > There's some other changes and improvements, but most of them are > > behind the scenes. > > -- > 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
Re: [OMPI devel] 1.3.1 -- bad MTT from Cisco
On Wed, Mar/11/2009 11:38:19AM, Jeff Squyres wrote: > As Terry stated, I think this bugger is quite rare. I'm having a helluva > time trying to reproduce it manually (over 5k runs this morning and still > no segv). Ugh. 5k of which test(s)? Can this error happen on any test? I am wondering if we could narrow down to a smaller subset of the nightly tests to reproduce this (the way Terry did by looping over the same test(s) for a looong time). I see the following over the past 30 days: # | Date range | Org | Hostname | Platform name | Hardware | OS| MPI name | MPI version| Suite| Test | np | Stdout | Pass | Fail | Skip | Timed | Perf 1 | 2009-02-12 06:47:56 | sun | burl-ct-v440-2| burl-ct-v440-2 | sun4u | SunOS | ompi-nightly-v1.3 | 1.3.1a0r20508 | ibm-64 | cxx_create_disp | 8 | btl_sm_add_procs | 0| 1| 0| 0 | 0 2 | 2009-02-27 23:37:02 | sun | burl-ct-v20z-2| burl-ct-v20z-2 | i86pc | SunOS | ompi-nightly-v1.3 | 1.3.1rc1r20628 | ibm-64 | lbub | 4 | btl_sm_add_procs | 0| 1| 0| 0 | 0 3 | 2009-03-05 00:15:39 | sun | burl-ct-v20z-2| burl-ct-v20z-2 | i86pc | SunOS | ompi-nightly-v1.3 | 1.3.1rc3r20684 | ibm-32 | loop | 4 | btl_sm_add_procs | 0| 1| 0| 0 | 0 4 | 2009-03-05 22:31:43 | sun | burl-ct-v20z-2| burl-ct-v20z-2 | i86pc | SunOS | ompi-nightly-v1.3 | 1.3.1rc4r20704 | intel-64 | MPI_Type_size_MPI_LB_UB_c | 4 | btl_sm_add_procs | 0| 1| 0| 0 | 0 5 | 2009-03-10 14:47:36 | cisco | svbu-mpi[035-036] | svbu-mpi | x86_64 | Linux | ompi-nightly-v1.3 | 1.3.1rc5r20730 | intel| MPI_Test_cancelled_false_c | 8 | btl_sm_add_procs | 0| 1| 0| 0 | 0 What do these tests have in common? ./intel_tests/src/MPI_Test_cancelled_false_c.c ./intel_tests/src/MPI_Type_size_MPI_LB_UB_c.c ./ibm/onesided/cxx_create_disp.cc ./ibm/datatype/lbub2.c ./ibm/datatype/loop.c ./ibm/datatype/lbub.c It almost looks like the problem is more likely to occur if MPI_UB or MPI_LB is involved or am I just imagining things? -Ethan > > Looking through the sm startup code, I can't see exactly what the problem > would be. :-( > > > On Mar 11, 2009, at 11:34 AM, Ralph Castain wrote: > >> I'll run some tests with 1.3.1 on one of our systems and see if it >> shows up there. If it is truly rare and was in 1.3.0, then I >> personally don't have a problem with it. Got bigger problems with >> hanging collectives, frankly - and we don't know how the sm changes >> will affect this problem, if at all. >> >> >> On Mar 11, 2009, at 7:50 AM, Terry Dontje wrote: >> >> > Jeff Squyres wrote: >> >> So -- Brad/George -- this technically isn't a regression against >> >> v1.3.0 (do we know if this can happen in 1.2? I don't recall >> >> seeing it there, but if it's so elusive... I haven't been MTT >> >> testing the 1.2 series in a long time). But it is a nonzero problem. >> >> >> > I have not seen 1.2 fail with this problem but I honestly don't know >> > if that is a fluke or not. >> > >> > --td >> > >> >> Should we release 1.3.1 without a fix? >> >> >> > >> >> >> >> On Mar 11, 2009, at 7:30 AM, Ralph Castain wrote: >> >> >> >>> I actually wasn't implying that Eugene's changes -caused- the >> >>> problem, >> >>> but rather that I thought they might have -fixed- the problem. >> >>> >> >>> :-) >> >>> >> >>> >> >>> On Mar 11, 2009, at 4:34 AM, Terry Dontje wrote: >> >>> >> >>> > I forgot to mention that since I ran into this issue so long ago I >> >>> > really doubt that Eugene's SM changes has caused this issue. >> >>> > >> >>> > --td >> >>> > >> >>> > Terry Dontje wrote: >> >>> >> Hey!!! I ran into this problem many months ago but its been so >> >>> >> elusive that I've haven't nailed it down. First time we saw this >> >>> >> was last October. I did some MTT gleaning and could not find >> >>> >> anyone but Solaris having this issue under MTT. What's >> >>> interesting >> >>> >> is I gleaned Sun's MTT results and could not find any of these >> >>> >> failures as far back as last October. >> >>> >> What it looked like to me was that the shared memory segment >> >>> might >> >>> >> not have been initialized with 0's thus allowing one of the >> >>> >> processes to start accessing addresses that did not have an >> >>> >> appropriate address. However, when I was looking at this I was >> >>> >> told the mmap file was created with ftruncate which essentially >> >>> >> should 0 fill the memory. So I was at a loss as to why this was >> >>> >> happening. >> >>> >> >> >>> >> I was able to reproduce this for a little while manually >> >>> setting up >> >>> >> a script that ran and small np=2 program over and over for >> >>> sometime >> >>> >> under 3-4 days. But around November I was unable to reproduce >> >>> the >> >>> >> issue after 4 days of runs and threw up my hand
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r20003 (Solaris malloc.h issue)
Hi, I think I have a better fix for this issue. It is to simply #include *before* ompi_config.h. --- ompi/mca/common/mx/common_mx.c +++ ompi/mca/common/mx/common_mx.c @@ -19,15 +19,16 @@ * $HEADER$ */ +#ifdef HAVE_MALLOC_H +#include +#endif + #include "ompi_config.h" #include "orte/util/show_help.h" #include "ompi/constants.h" #include "common_mx.h" #include -#ifdef HAVE_MALLOC_H -#include -#endif #include "opal/memoryhooks/memory.h" #include "opal/mca/base/mca_base_param.h" #include "ompi/runtime/params.h" The reason for doing this is because ompi_config.h (which includes ompi_config_bottom.h) #defines "malloc", so we end up with OMPI code getting spliced into the Solaris /usr/include/malloc.h code. Is this fix okay? -Ethan On Wed, Dec/10/2008 04:29:31PM, Ethan Mallove wrote: > Hi Patrick, > > r20003 seems to break MX support on Solaris. > > $ cd ompi/mca/common/mx > $ make > ... > "/usr/include/malloc.h", line 46: syntax error before or at: ( > "/usr/include/malloc.h", line 47: syntax error before or at: ( > "/usr/include/malloc.h", line 48: syntax error before or at: ( > "/usr/include/malloc.h", line 48: cannot have void object: size_t > "/usr/include/malloc.h", line 48: identifier redeclared: size_t > ... <4000 more lines of compiler errors> ... > > The below patch makes it so opal/util/malloc.h is used instead of > /usr/include/malloc.h and the compiler errors go away. (I also needed > to include errno.h.) Would this be okay to do? > > diff -r 347f52a3713f ompi/mca/common/mx/common_mx.c > --- ompi/mca/common/mx/common_mx.c > +++ ompi/mca/common/mx/common_mx.c > @@ -23,9 +23,8 @@ >#include "ompi/constants.h" >#include "common_mx.h" > > -#ifdef HAVE_MALLOC_H > -#include > -#endif > +#include > +#include "opal/util/malloc.h" >#include "opal/memoryhooks/memory.h" >#include "opal/mca/base/mca_base_param.h" >#include "ompi/runtime/params.h" > > I tested the above on Solaris and Linux with SunStudio. > > Regards, > Ethan > > > On Fri, Nov/14/2008 11:17:59PM, patr...@osl.iu.edu wrote: > > Author: patrick > > Date: 2008-11-14 23:17:58 EST (Fri, 14 Nov 2008) > > New Revision: 20003 > > URL: https://svn.open-mpi.org/trac/ompi/changeset/20003 > > > > Log: > > Define a "fake" mpool to provide a memory release callback for the > > memory hooks (munmap) and initialize the mallopt component, and > > nothing else. > > Use this mpool in the MX common initialization, supporting both BTL > > and MTL. Automatically set the MX_RCACHE environment variable to > > enable registration cache in MX. > > > > Tested with success for munmap() and large free(). > > > > > > Added: > >trunk/ompi/mca/mpool/fake/ > >trunk/ompi/mca/mpool/fake/Makefile.am > >trunk/ompi/mca/mpool/fake/configure.params > >trunk/ompi/mca/mpool/fake/mpool_fake.h > >trunk/ompi/mca/mpool/fake/mpool_fake_component.c > >trunk/ompi/mca/mpool/fake/mpool_fake_module.c > > Text files modified: > >trunk/ompi/mca/common/mx/common_mx.c |56 > > +++ > >1 files changed, 55 insertions(+), 1 deletions(-) > > > > Modified: trunk/ompi/mca/common/mx/common_mx.c > > == > > --- trunk/ompi/mca/common/mx/common_mx.c(original) > > +++ trunk/ompi/mca/common/mx/common_mx.c2008-11-14 23:17:58 EST (Fri, > > 14 Nov 2008) > > @@ -9,6 +9,8 @@ > > * University of Stuttgart. All rights reserved. > > * Copyright (c) 2004-2006 The Regents of the University of California. > > * All rights reserved. > > + * Copyright (c) 2008 Myricom. All rights reserved. > > + * > > * $COPYRIGHT$ > > * > > * Additional copyrights may follow > > @@ -21,11 +23,29 @@ > > #include "ompi/constants.h" > > #include "common_mx.h" > > > > +#ifdef HAVE_MALLOC_H > > +#include > > +#endif > > +#include "opal/memoryhooks/memory.h" > > +#include "opal/mca/base/mca_base_param.h" > > +#include "ompi/runtime/params.h" > > +#include "ompi/mca/mpool/mpool.h" > > +#include "ompi/mca/mpool/base/base.h" > > +#include "ompi/mca/mpool/fa
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r20003 (Solaris malloc.h issue)
On Thu, Apr/16/2009 06:18:27PM, George Bosilca wrote: > I don't think this is correct. We are not supposed to include > anything before the ompi_config.h. Moreover, in the case we redefine > what malloc is, this will be the only piece of code that will use > the real malloc. > > I wonder why we need to include malloc.h there? We don't allocate > any memory in this file ... Any objections to removing the #include line? -Ethan > > george. > > On Apr 16, 2009, at 18:09 , Ethan Mallove wrote: > >> Hi, >> >> I think I have a better fix for this issue. It is to simply #include >> *before* ompi_config.h. >> >> --- ompi/mca/common/mx/common_mx.c >> +++ ompi/mca/common/mx/common_mx.c >> @@ -19,15 +19,16 @@ >>* $HEADER$ >>*/ >> >> +#ifdef HAVE_MALLOC_H >> +#include >> +#endif >> + >> #include "ompi_config.h" >> #include "orte/util/show_help.h" >> #include "ompi/constants.h" >> #include "common_mx.h" >> >> #include >> -#ifdef HAVE_MALLOC_H >> -#include >> -#endif >> #include "opal/memoryhooks/memory.h" >> #include "opal/mca/base/mca_base_param.h" >> #include "ompi/runtime/params.h" >> >> The reason for doing this is because ompi_config.h (which includes >> ompi_config_bottom.h) #defines "malloc", so we end up with OMPI code >> getting spliced into the Solaris /usr/include/malloc.h code. >> >> Is this fix okay? >> >> -Ethan >> >> On Wed, Dec/10/2008 04:29:31PM, Ethan Mallove wrote: >>> Hi Patrick, >>> >>> r20003 seems to break MX support on Solaris. >>> >>> $ cd ompi/mca/common/mx >>> $ make >>> ... >>> "/usr/include/malloc.h", line 46: syntax error before or at: ( >>> "/usr/include/malloc.h", line 47: syntax error before or at: ( >>> "/usr/include/malloc.h", line 48: syntax error before or at: ( >>> "/usr/include/malloc.h", line 48: cannot have void object: size_t >>> "/usr/include/malloc.h", line 48: identifier redeclared: size_t >>> ... <4000 more lines of compiler errors> ... >>> >>> The below patch makes it so opal/util/malloc.h is used instead of >>> /usr/include/malloc.h and the compiler errors go away. (I also needed >>> to include errno.h.) Would this be okay to do? >>> >>> diff -r 347f52a3713f ompi/mca/common/mx/common_mx.c >>> --- ompi/mca/common/mx/common_mx.c >>> +++ ompi/mca/common/mx/common_mx.c >>> @@ -23,9 +23,8 @@ >>> #include "ompi/constants.h" >>> #include "common_mx.h" >>> >>> -#ifdef HAVE_MALLOC_H >>> -#include >>> -#endif >>> +#include >>> +#include "opal/util/malloc.h" >>> #include "opal/memoryhooks/memory.h" >>> #include "opal/mca/base/mca_base_param.h" >>> #include "ompi/runtime/params.h" >>> >>> I tested the above on Solaris and Linux with SunStudio. >>> >>> Regards, >>> Ethan >>> >>> >>> On Fri, Nov/14/2008 11:17:59PM, patr...@osl.iu.edu wrote: >>>> Author: patrick >>>> Date: 2008-11-14 23:17:58 EST (Fri, 14 Nov 2008) >>>> New Revision: 20003 >>>> URL: https://svn.open-mpi.org/trac/ompi/changeset/20003 >>>> >>>> Log: >>>> Define a "fake" mpool to provide a memory release callback for the >>>> memory hooks (munmap) and initialize the mallopt component, and >>>> nothing else. >>>> Use this mpool in the MX common initialization, supporting both BTL >>>> and MTL. Automatically set the MX_RCACHE environment variable to >>>> enable registration cache in MX. >>>> >>>> Tested with success for munmap() and large free(). >>>> >>>> >>>> Added: >>>> trunk/ompi/mca/mpool/fake/ >>>> trunk/ompi/mca/mpool/fake/Makefile.am >>>> trunk/ompi/mca/mpool/fake/configure.params >>>> trunk/ompi/mca/mpool/fake/mpool_fake.h >>>> trunk/ompi/mca/mpool/fake/mpool_fake_component.c >>>> trunk/ompi/mca/mpool/fake/mpool_fake_module.c >>>> Text files modified: >>>> trunk/ompi/mca/common/mx/common_mx.c |56 >>>> +++ >>>> 1 files changed, 55 insertions(+)
Re: [OMPI devel] [OMPI svn] svn:open-mpi r22014
On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
> I think there is a problem with this change - here is a warning I get when
> compiling on Mac and Linux:
>
> ompi_debuggers.c:265: warning: no previous prototype for ?MPIR_Breakpoint?
>
> Can you please take a look?
Can you send me your config.log file? I can't reproduce the warning
using GCC (3.4.6) on RHEL 4.
-Ethan
>
> Thanks
> Ralph
>
> On Sep 25, 2009, at 1:14 PM, emall...@osl.iu.edu wrote:
>
>> Author: emallove
>> Date: 2009-09-25 15:14:19 EDT (Fri, 25 Sep 2009)
>> New Revision: 22014
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/22014
>>
>> Log:
>> Remove `static` from `MPIR_Breakpoint` so Intel compilers will not inline
>> it
>>
>> Text files modified:
>> trunk/ompi/debuggers/ompi_debuggers.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> Modified: trunk/ompi/debuggers/ompi_debuggers.c
>> ==
>> --- trunk/ompi/debuggers/ompi_debuggers.c(original)
>> +++ trunk/ompi/debuggers/ompi_debuggers.c2009-09-25 15:14:19 EDT (Fri,
>> 25
>> Sep 2009)
>> @@ -261,7 +261,7 @@
>> * defined in orterun for the starter. It should never conflict with
>> * this one, but we'll make it static, just to be sure.
>> */
>> -static void *MPIR_Breakpoint(void)
>> +void *MPIR_Breakpoint(void)
>> {
>> return NULL;
>> }
>> ___
>> svn mailing list
>> s...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/svn
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [OMPI svn] svn:open-mpi r22014
On Mon, Sep/28/2009 02:05:14PM, Jeff Squyres wrote:
> Try a newer compiler than gcc 3.4 -- it's pretty ancient.
I don't get the warning with 4.1.2 either.
-Ethan
>
>
> On Sep 28, 2009, at 2:03 PM, Ethan Mallove wrote:
>
>> On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
>> > I think there is a problem with this change - here is a warning I get
>> when
>> > compiling on Mac and Linux:
>> >
>> > ompi_debuggers.c:265: warning: no previous prototype for
>> ?MPIR_Breakpoint?
>> >
>> > Can you please take a look?
>>
>> Can you send me your config.log file? I can't reproduce the warning
>> using GCC (3.4.6) on RHEL 4.
>>
>> -Ethan
>>
>> >
>> > Thanks
>> > Ralph
>> >
>> > On Sep 25, 2009, at 1:14 PM, emall...@osl.iu.edu wrote:
>> >
>> >> Author: emallove
>> >> Date: 2009-09-25 15:14:19 EDT (Fri, 25 Sep 2009)
>> >> New Revision: 22014
>> >> URL: https://svn.open-mpi.org/trac/ompi/changeset/22014
>> >>
>> >> Log:
>> >> Remove `static` from `MPIR_Breakpoint` so Intel compilers will not
>> inline
>> >> it
>> >>
>> >> Text files modified:
>> >> trunk/ompi/debuggers/ompi_debuggers.c | 2 +-
>> >> 1 files changed, 1 insertions(+), 1 deletions(-)
>> >>
>> >> Modified: trunk/ompi/debuggers/ompi_debuggers.c
>> >>
>> ==
>> >> --- trunk/ompi/debuggers/ompi_debuggers.c(original)
>> >> +++ trunk/ompi/debuggers/ompi_debuggers.c2009-09-25 15:14:19 EDT
>> (Fri, 25
>> >> Sep 2009)
>> >> @@ -261,7 +261,7 @@
>> >> * defined in orterun for the starter. It should never conflict with
>> >> * this one, but we'll make it static, just to be sure.
>> >> */
>> >> -static void *MPIR_Breakpoint(void)
>> >> +void *MPIR_Breakpoint(void)
>> >> {
>> >> return NULL;
>> >> }
>> >> ___
>> >> svn mailing list
>> >> s...@open-mpi.org
>> >> http://www.open-mpi.org/mailman/listinfo.cgi/svn
>> >
>> >
>> > ___
>> > devel mailing list
>> > de...@open-mpi.org
>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [OMPI svn] svn:open-mpi r22014
On Mon, Sep/28/2009 03:11:46PM, Ethan Mallove wrote:
> On Mon, Sep/28/2009 02:05:14PM, Jeff Squyres wrote:
> > Try a newer compiler than gcc 3.4 -- it's pretty ancient.
>
> I don't get the warning with 4.1.2 either.
To get the warning I needed to enable some developer configure options (e.g.,
mkdir .svn && configure).
The below patch gets rid of the warning, but is it the right way?
--- ompi/debuggers/debuggers.h
+++ ompi/debuggers/debuggers.h
@@ -40,6 +40,11 @@
*/
OMPI_DECLSPEC void ompi_debugger_notify_abort(char *string);
+/**
+ * Breakpoint function for parallel debuggers.
+ */
+OMPI_DECLSPEC void *MPIR_Breakpoint(void);
+
END_C_DECLS
#endif /* OMPI_DEBUGGERS_H */
-Ethan
>
> -Ethan
>
> >
> >
> > On Sep 28, 2009, at 2:03 PM, Ethan Mallove wrote:
> >
> >> On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
> >> > I think there is a problem with this change - here is a warning I get
> >> when
> >> > compiling on Mac and Linux:
> >> >
> >> > ompi_debuggers.c:265: warning: no previous prototype for
> >> ?MPIR_Breakpoint?
> >> >
> >> > Can you please take a look?
> >>
> >> Can you send me your config.log file? I can't reproduce the warning
> >> using GCC (3.4.6) on RHEL 4.
> >>
> >> -Ethan
> >>
> >> >
> >> > Thanks
> >> > Ralph
> >> >
> >> > On Sep 25, 2009, at 1:14 PM, emall...@osl.iu.edu wrote:
> >> >
> >> >> Author: emallove
> >> >> Date: 2009-09-25 15:14:19 EDT (Fri, 25 Sep 2009)
> >> >> New Revision: 22014
> >> >> URL: https://svn.open-mpi.org/trac/ompi/changeset/22014
> >> >>
> >> >> Log:
> >> >> Remove `static` from `MPIR_Breakpoint` so Intel compilers will not
> >> inline
> >> >> it
> >> >>
> >> >> Text files modified:
> >> >> trunk/ompi/debuggers/ompi_debuggers.c | 2 +-
> >> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >> >>
> >> >> Modified: trunk/ompi/debuggers/ompi_debuggers.c
> >> >>
> >> ==
> >> >> --- trunk/ompi/debuggers/ompi_debuggers.c(original)
> >> >> +++ trunk/ompi/debuggers/ompi_debuggers.c2009-09-25 15:14:19 EDT
> >> (Fri, 25
> >> >> Sep 2009)
> >> >> @@ -261,7 +261,7 @@
> >> >> * defined in orterun for the starter. It should never conflict with
> >> >> * this one, but we'll make it static, just to be sure.
> >> >> */
> >> >> -static void *MPIR_Breakpoint(void)
> >> >> +void *MPIR_Breakpoint(void)
> >> >> {
> >> >> return NULL;
> >> >> }
> >> >> ___
> >> >> svn mailing list
> >> >> s...@open-mpi.org
> >> >> http://www.open-mpi.org/mailman/listinfo.cgi/svn
> >> >
> >> >
> >> > ___
> >> > devel mailing list
> >> > de...@open-mpi.org
> >> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>
> >>
> >
> >
> > --
> > Jeff Squyres
> > jsquy...@cisco.com
> >
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r22077
I think we're missing a couple semicolons (see below).
On Thu, Oct/08/2009 01:53:43PM, r...@osl.iu.edu wrote:
> Author: rhc
> Date: 2009-10-08 13:53:43 EDT (Thu, 08 Oct 2009)
> New Revision: 22077
> URL: https://svn.open-mpi.org/trac/ompi/changeset/22077
>
> Log:
> Closes #2048: Fix uninitialized variable in MPI_Comm_spawn_multiple
>
> Submitted by tdd, reviewed by jsquyres, RM-approved by bbenton
>
> Includes r22075 and r22076
>
>
> Properties modified:
>branches/v1.3/ (props changed)
> Text files modified:
>branches/v1.3/ompi/mpi/c/comm_spawn.c | 5 +
>
>branches/v1.3/ompi/mpi/c/comm_spawn_multiple.c | 7 ++-
>
>2 files changed, 11 insertions(+), 1 deletions(-)
>
> Modified: branches/v1.3/ompi/mpi/c/comm_spawn.c
> ==
> --- branches/v1.3/ompi/mpi/c/comm_spawn.c (original)
> +++ branches/v1.3/ompi/mpi/c/comm_spawn.c 2009-10-08 13:53:43 EDT (Thu,
> 08 Oct 2009)
> @@ -10,6 +10,7 @@
> * Copyright (c) 2004-2005 The Regents of the University of California.
> * All rights reserved.
> * Copyright (c) 2006-2007 Cisco Systems, Inc. All rights reserved.
> + * Copyright (c) 2009 Sun Microsystems, Inc. All rights reserved.
> * $COPYRIGHT$
> *
> * Additional copyrights may follow
> @@ -106,6 +107,10 @@
> if (OMPI_SUCCESS != (rc = ompi_dpm.open_port (port_name,
> OMPI_RML_TAG_INVALID))) {
> goto error;
> }
> +} else if (1 < ompi_comm_size(comm)) {
> + /* we do not support non_mpi spawns on comms this size */
> + rc = OMPI_ERR_NOT_SUPPORTED
Here.
> + goto error;
> }
> if (OMPI_SUCCESS != (rc = ompi_dpm.spawn (1, &command, &argv,
> &maxprocs,
>&info, port_name))) {
>
> Modified: branches/v1.3/ompi/mpi/c/comm_spawn_multiple.c
> ==
> --- branches/v1.3/ompi/mpi/c/comm_spawn_multiple.c(original)
> +++ branches/v1.3/ompi/mpi/c/comm_spawn_multiple.c2009-10-08 13:53:43 EDT
> (Thu, 08 Oct 2009)
> @@ -10,6 +10,7 @@
> * Copyright (c) 2004-2005 The Regents of the University of California.
> * All rights reserved.
> * Copyright (c) 2006 Cisco Systems, Inc. All rights reserved.
> + * Copyright (c) 2009 Sun Microsystems, Inc. All rights reserved.
> * $COPYRIGHT$
> *
> * Additional copyrights may follow
> @@ -45,7 +46,7 @@
> ompi_communicator_t *newcomp=NULL;
> bool send_first=false; /* they are contacting us first */
> char port_name[MPI_MAX_PORT_NAME];
> -bool non_mpi, cumulative = false;
> +bool non_mpi = false, cumulative = false;
>
> MEMCHECKER(
> memchecker_comm(comm);
> @@ -146,6 +147,10 @@
> if (OMPI_SUCCESS != (rc = ompi_dpm.open_port (port_name,
> OMPI_RML_TAG_INVALID))) {
> goto error;
> }
> +} else if (1 < ompi_comm_size(comm)) {
> + /* we do not support non_mpi spawns on comms this size */
> + rc = OMPI_ERR_NOT_SUPPORTED
And here.
-Ethan
> + goto error;
> }
> if (OMPI_SUCCESS != (rc = ompi_dpm.spawn(count, array_of_commands,
> array_of_argv,
> array_of_maxprocs,
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r22663
About this change - I have been seeing the below error while trying to build the trunk recently: $ make ... cd . && /bin/bash /tmp/config-missing-bug-in-trunk/trunk/config/missing --run aclocal-1.10 -I config configure.ac:939: warning: OMPI_CONFIGURE_SETUP is m4_require'd but not m4_defun'd config/ompi_mca.m4:37: OMPI_MCA is expanded from... configure.ac:939: the top level cd . && /bin/bash /tmp/config-missing-bug-in-trunk/trunk/config/missing --run automake-1.10 --foreign configure.ac:939: warning: OMPI_CONFIGURE_SETUP is m4_require'd but not m4_defun'd ... ompi/mca/allocator/Makefile.am:31: WANT_INSTALL_HEADERS does not appear in AM_CONDITIONAL ... repeats 49 times ... make: *** [configure] Error 1 While fixing ACLOCAL_AMFLAGS gets the build to complete successfully, the real issue is: why is config/missing getting immediately invoked by "make"? This wasn't happening before, and it means configure is getting run twice per build now. Any ideas what could be causing this? -Ethan On Thu, Feb/18/2010 01:11:23PM, emall...@osl.iu.edu wrote: > Author: emallove > Date: 2010-02-18 13:11:23 EST (Thu, 18 Feb 2010) > New Revision: 22663 > URL: https://svn.open-mpi.org/trac/ompi/changeset/22663 > > Log: > In case `config/missing` gets invoked, ensure that all the OMPI-specific m4 > macros are defined. > > Text files modified: >trunk/Makefile.am | 2 +- >1 files changed, 1 insertions(+), 1 deletions(-) > > Modified: trunk/Makefile.am > == > --- trunk/Makefile.am (original) > +++ trunk/Makefile.am 2010-02-18 13:11:23 EST (Thu, 18 Feb 2010) > @@ -25,4 +25,4 @@ > dist-hook: > csh "$(top_srcdir)/config/distscript.csh" "$(top_srcdir)" "$(distdir)" > "$(OMPI_VERSION)" "$(OMPI_SVN_R)" > > -ACLOCAL_AMFLAGS = -I config > +ACLOCAL_AMFLAGS = -I config -I opal/config -I ompi/config -I orte/config > ___ > svn-full mailing list > svn-f...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r22663
On Thu, Feb/18/2010 01:16:33PM, Jeff Squyres wrote: > On Feb 18, 2010, at 1:12 PM, Ethan Mallove wrote: > > > About this change - I have been seeing the below error while trying to > > build the trunk recently: > > > > $ make ... > > cd . && /bin/bash /tmp/config-missing-bug-in-trunk/trunk/config/missing > > --run aclocal-1.10 -I config > > configure.ac:939: warning: OMPI_CONFIGURE_SETUP is m4_require'd but not > > m4_defun'd > > config/ompi_mca.m4:37: OMPI_MCA is expanded from... > > configure.ac:939: the top level > >cd . && /bin/bash /tmp/config-missing-bug-in-trunk/trunk/config/missing > > --run automake-1.10 --foreign > > configure.ac:939: warning: OMPI_CONFIGURE_SETUP is m4_require'd but not > > m4_defun'd > > ... > > > > While fixing ACLOCAL_AMFLAGS gets the build to complete successfully, > > the real issue is: why is config/missing getting immediately invoked > > by "make"? This wasn't happening before, and it means configure is > > getting run twice per build now. > > > > Any ideas what could be causing this? > > No -- it should not be happening. I'd think that those extra -I's shouldn't > be necessary. > > Check the usual suspects, such as time synchronization between NFS client and > server, etc. > > You might also want to run "make -d" to see what rules are being invoked and > why. make -d shows the problem: ... Prerequisite `config/libtool.m4' is newer than target `aclocal.m4'. ... Must remake target `aclocal.m4'. ... This occurs because autogen.sh patches aclocal.m4 before patching libtool.m4. I don't know why we're suddenly seeing this now, but this vile hack fixes it: Index: autogen.sh === --- autogen.sh +++ autogen.sh @@ -594,6 +594,9 @@ rm -f libtool.m4.rej fi +# Ensure libtool.m4 is very old so that make does not rebuild aclocal.m4 +touch -t 19700101.00 config/libtool.m4 + run_and_check $ompi_autoconf run_and_check $ompi_automake --foreign -a --copy --include-deps -Ethan > > -- > 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
Re: [OMPI devel] System V Shared Memory for Open MPI: Request for Community Input and Testing
Hi Samuel, I'm trying to run off your HG clone, but I'm seeing issues with c_hello, e.g., $ mpirun -mca mpi_common_sm sysv --mca btl self,sm,tcp --host burl-ct-v440-2,burl-ct-v440-2 -np 2 ./c_hello -- A system call failed during shared memory initialization that should not have. It is likely that your MPI job will now either abort or experience performance degradation. Local host: burl-ct-v440-2 System call: shmat(2) Process: [[43408,1],1] Error: Invalid argument (errno 22) -- ^Cmpirun: killing job... $ uname -a SunOS burl-ct-v440-2 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V440 The same test works okay if I s/sysv/mmap/. Regards, Ethan On Wed, Apr/28/2010 07:16:12AM, Samuel K. Gutierrez wrote: > Hi, > > Faster component initialization/finalization times is one of the main > motivating factors of this work. The general idea is to get away from > creating a rather large backing file. With respect to module bandwidth and > latency, mmap and sysv seem to be comparable - at least that is what my > preliminary tests have shown. As it stands, I have not come across a > situation where the mmap SM component doesn't work or is slower. > > Hope that helps, > > -- > Samuel K. Gutierrez > Los Alamos National Laboratory > > > > > > On Apr 28, 2010, at 5:35 AM, Bogdan Costescu wrote: > > > On Tue, Apr 27, 2010 at 7:55 PM, Samuel K. Gutierrez > > wrote: > >> With Jeff and Ralph's help, I have completed a System V shared memory > >> component for Open MPI. > > > > What is the motivation for this work ? Are there situations where the > > mmap based SM component doesn't work or is slow(er) ? > > > > Kind regards, > > Bogdan > > ___ > > 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] System V Shared Memory for Open MPI: Request for Community Input and Testing
On Thu, Apr/29/2010 02:52:24PM, Samuel K. Gutierrez wrote: > Hi Ethan, > > Bummer. What does the following command show? > > sysctl -a | grep shm In this case, I think the Solaris equivalent to sysctl is prctl, e.g., $ prctl -i project group.staff project: 10: group.staff NAMEPRIVILEGE VALUEFLAG ACTION RECIPIENT ... project.max-shm-memory privileged 3.92GB - deny - system 16.0EBmax deny - project.max-shm-ids privileged128 - deny - system 16.8M max deny - ... Is that the info you need? -Ethan > > Thanks! > > -- > Samuel K. Gutierrez > Los Alamos National Laboratory > > On Apr 29, 2010, at 1:32 PM, Ethan Mallove wrote: > > > Hi Samuel, > > > > I'm trying to run off your HG clone, but I'm seeing issues with > > c_hello, e.g., > > > > $ mpirun -mca mpi_common_sm sysv --mca btl self,sm,tcp --host > > burl-ct-v440-2,burl-ct-v440-2 -np 2 ./c_hello > > -- > > A system call failed during shared memory initialization that should > > not have. It is likely that your MPI job will now either abort or > > experience performance degradation. > > > >Local host: burl-ct-v440-2 > >System call: shmat(2) > >Process: [[43408,1],1] > >Error: Invalid argument (errno 22) > > -- > > ^Cmpirun: killing job... > > > > $ uname -a > > SunOS burl-ct-v440-2 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V440 > > > > The same test works okay if I s/sysv/mmap/. > > > > Regards, > > Ethan > > > > > > On Wed, Apr/28/2010 07:16:12AM, Samuel K. Gutierrez wrote: > >> Hi, > >> > >> Faster component initialization/finalization times is one of the main > >> motivating factors of this work. The general idea is to get away from > >> creating a rather large backing file. With respect to module bandwidth > >> and > >> latency, mmap and sysv seem to be comparable - at least that is what my > >> preliminary tests have shown. As it stands, I have not come across a > >> situation where the mmap SM component doesn't work or is slower. > >> > >> Hope that helps, > >> > >> -- > >> Samuel K. Gutierrez > >> Los Alamos National Laboratory > >> > >> > >> > >> > >> > >> On Apr 28, 2010, at 5:35 AM, Bogdan Costescu wrote: > >> > >>> On Tue, Apr 27, 2010 at 7:55 PM, Samuel K. Gutierrez > >>> wrote: > >>>> With Jeff and Ralph's help, I have completed a System V shared memory > >>>> component for Open MPI. > >>> > >>> What is the motivation for this work ? Are there situations where the > >>> mmap based SM component doesn't work or is slow(er) ? > >>> > >>> Kind regards, > >>> Bogdan > >>> ___ > >>> 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
[OMPI devel] GCC Linux trunk build errors in paffinity/hwloc
IU and Oracle GCC/Linux nightly trunk builds are both dying on: ... Entering directory `.../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/src' CC traversal.lo CC topology.lo CC topology-synthetic.lo CC bind.lo CC cpuset.lo CC misc.lo CC topology-xml.lo CC topology-linux.lo CC topology-x86.lo topology-x86.c: In function 'look_proc': .../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54: error: can't find a register in class 'BREG' while reloading 'asm' .../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54: error: can't find a register in class 'BREG' while reloading 'asm' .../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54: error: can't find a register in class 'BREG' while reloading 'asm' .../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54: error: can't find a register in class 'BREG' while reloading 'asm' .../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54: error: can't find a register in class 'BREG' while reloading 'asm' .../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54: error: can't find a register in class 'BREG' while reloading 'asm' .../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54: error: can't find a register in class 'BREG' while reloading 'asm' .../openmpi-1.7a1r23202/opal/mca/paffinity/hwloc/hwloc/include/private/cpuid.h:54: error: can't find a register in class 'BREG' while reloading 'asm' make[4]: *** [topology-x86.lo] Error 1 http://www.open-mpi.org/mtt/index.php?do_redir=1856 -Ethan
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23665
This fixes Libtool for an SVN checkout, but does not seem to get into
the nightly trunk tarball. Why is that?
-Ethan
On Wed, Aug/25/2010 03:40:18PM, emall...@osl.iu.edu wrote:
> Author: emallove
> Date: 2010-08-25 15:40:17 EDT (Wed, 25 Aug 2010)
> New Revision: 23665
> URL: https://svn.open-mpi.org/trac/ompi/changeset/23665
>
> Log:
> Patch `ltmain.sh` in `autogen.sh` per this Libtool thread:
> http://www.mail-archive.com/libtool@gnu.org/msg11249.html
>
> Added:
>trunk/config/ltmain_pgi_tp.diff
> Text files modified:
>trunk/autogen.sh | 8
>1 files changed, 8 insertions(+), 0 deletions(-)
>
> Modified: trunk/autogen.sh
> ==
> --- trunk/autogen.sh (original)
> +++ trunk/autogen.sh 2010-08-25 15:40:17 EDT (Wed, 25 Aug 2010)
> @@ -11,6 +11,7 @@
> # Copyright (c) 2004-2005 The Regents of the University of California.
> # All rights reserved.
> # Copyright (c) 2007-2010 Cisco Systems, Inc. All rights reserved.
> +# Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
> # $COPYRIGHT$
> #
> # Additional copyrights may follow
> @@ -442,6 +443,13 @@
>
> echo "** Adjusting libltdl for OMPI :-("
>
> +echo " ++ patching PGI -tp bug in ltmain.sh"
> +if test -z "`grep -w tp config/ltmain.sh`"; then
> +patch -N -p0 < config/ltmain_pgi_tp.diff
> +else
> +echo " -- your libtool doesn't need this! yay!"
> +fi
> +
> echo " ++ preopen error masking ib libltdl"
> if test -r opal/libltdl/loaders/preopen.c; then
> patch -N -p0 < config/libltdl-preopen-error.diff
>
> Added: trunk/config/ltmain_pgi_tp.diff
> ==
> --- (empty file)
> +++ trunk/config/ltmain_pgi_tp.diff 2010-08-25 15:40:17 EDT (Wed, 25 Aug
> 2010)
> @@ -0,0 +1,11 @@
> +--- config/ltmain.sh
> config/ltmain.sh
> +@@ -4765,7 +4765,7 @@
> + # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC
> + # @file GCC response files
> + -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
> +- -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*)
> ++ -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp|-tp=*)
> + func_quote_for_eval "$arg"
> +arg="$func_quote_for_eval_result"
> + func_append compile_command " $arg"
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
[OMPI devel] MTT for developers
All, MTT can now be used to test your developer workspaces. The quick, cut-n-paste way to get started is: $ svn co https://svn.open-mpi.org/svn/mtt/branches/ompi-core-testers $ cd samples $ cat developer.ini trivial.ini | ../client/mtt - hostlist=host1,host2 alreadyinstalled_dir=/your/mpi/installation Where "host1" and "host2" are the hosts you want to run tests on, and "/your/mpi/installation" is where your MPI is installed (what you would pass to mpirun's --prefix). A more thorough HOWTO is here: https://svn.open-mpi.org/trac/mtt/wiki/AlreadyInstalled Please report any questions and/or issues to mtt-us...@open-mpi.org. Cheers, Ethan
[OMPI devel] Outdated PMB_2.2 test suite
All, Would anyone be opposed to me removing the PMB_2.2 test suite from the ompi-tests repository? IMB_2.3 (also in the ompi-tests repository) is more up-to-date. If I don't hear any objections by COB Wednesday, I'll delete PMB_2.2. -Ethan
Re: [OMPI devel] Fwd: [OMPI svn] svn:open-mpi r16563
Whoa! My apologies. I saw the same behavior when I did:
$ rm -rf ~/.svk
I think if we check the existence of $HOME/.svk before doing
any svk commands then we should be okay. I did that in
r16586. Does it work for you now?
-Ethan
On Fri, Oct/26/2007 02:02:42PM, George Bosilca wrote:
> This patch break the autogen.sh in the case svk is
> available on the node. I try it on MAC OS X as well as
> Linux boxes, and svk info will try to create the svk if
> the project is not svk based. In fact it ask the user if
> he want to create the svk stuff, but the output is hidden
> by the autogen.sh so it just stay there forever.
>
> Thanks,
> george.
>
> Begin forwarded message:
>
>> From: emall...@osl.iu.edu
>> Date: October 25, 2007 10:12:53 AM EDT
>> To: s...@open-mpi.org
>> Subject: [OMPI svn] svn:open-mpi r16563
>> Reply-To: de...@open-mpi.org
>>
>> Author: emallove
>> Date: 2007-10-25 10:12:52 EDT (Thu, 25 Oct 2007)
>> New Revision: 16563
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/16563
>>
>> Log:
>> Sanity check for SVK workspace in autogen.sh.
>>
>> Text files modified:
>>trunk/autogen.sh |29 -
>>1 files changed, 28 insertions(+), 1 deletions(-)
>>
>> Modified: trunk/autogen.sh
>> ==
>> --- trunk/autogen.sh (original)
>> +++ trunk/autogen.sh 2007-10-25 10:12:52 EDT (Thu, 25 Oct 2007)
>> @@ -1103,6 +1103,32 @@
>> unset project project_path framework framework_path component
>> component_path
>> }
>>
>> +##
>> +#
>> +# check_for_svk_checkout - determine whether this is an SVK checkout
>> +#
>> +# INPUT:
>> +#none
>> +#
>> +# OUTPUT:
>> +#none
>> +#
>> +# SIDE EFFECTS:
>> +#
>> +##
>> +check_for_svk_checkout() {
>> +is_svk_checkout=0
>> +
>> +svk_path=`which svk 2>/dev/null`
>> +if test -x "$svk_path"; then
>> +top_level_dir="`dirname $0`"
>> +svk info $top_level_dir >/dev/null 2>&1
>> +if test "$?" = 0 ; then
>> +is_svk_checkout=1
>> +fi
>> +fi
>> +
>> +}
>>
>>
>> ##
>> #
>> @@ -1135,7 +1161,8 @@
>> echo "[Checking] prerequisites"
>>
>> # sanity check to make sure user isn't being stupid
>> -if test ! -d .svn ; then
>> +check_for_svk_checkout
>> +if test ! -d .svn -a ! $is_svk_checkout ; then
>> cat <>
>> This doesn't look like a developer copy of Open MPI. You probably do not
>> ___
>> svn mailing list
>> s...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/svn
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Fwd: [OMPI svn] svn:open-mpi r16563
George,
For me, SVK says the below on a non-SVK path (then it
immediately exits):
$ svk info /tmp
path /tmp is not a checkout path.
$ svk --version
This is svk, version 1.07.
What is the prompt that SVK gives you?
-Ethan
On Fri, Oct/26/2007 02:36:50PM, George Bosilca wrote:
> Ethan,
>
> It only solve half the problem. I do have some svk based
> directories on my system ... but not all my Open MPI
> checkouts are svk based. So, it still deadlock for me.
>
> george.
>
> On Oct 26, 2007, at 2:33 PM, Ethan Mallove wrote:
>
>> Whoa! My apologies. I saw the same behavior when I did:
>>
>> $ rm -rf ~/.svk
>>
>> I think if we check the existence of $HOME/.svk before doing
>> any svk commands then we should be okay. I did that in
>> r16586. Does it work for you now?
>>
>> -Ethan
>>
>>
>> On Fri, Oct/26/2007 02:02:42PM, George Bosilca wrote:
>>> This patch break the autogen.sh in the case svk is
>>> available on the node. I try it on MAC OS X as well as
>>> Linux boxes, and svk info will try to create the svk if
>>> the project is not svk based. In fact it ask the user if
>>> he want to create the svk stuff, but the output is hidden
>>> by the autogen.sh so it just stay there forever.
>>>
>>> Thanks,
>>> george.
>>>
>>> Begin forwarded message:
>>>
>>>> From: emall...@osl.iu.edu
>>>> Date: October 25, 2007 10:12:53 AM EDT
>>>> To: s...@open-mpi.org
>>>> Subject: [OMPI svn] svn:open-mpi r16563
>>>> Reply-To: de...@open-mpi.org
>>>>
>>>> Author: emallove
>>>> Date: 2007-10-25 10:12:52 EDT (Thu, 25 Oct 2007)
>>>> New Revision: 16563
>>>> URL: https://svn.open-mpi.org/trac/ompi/changeset/16563
>>>>
>>>> Log:
>>>> Sanity check for SVK workspace in autogen.sh.
>>>>
>>>> Text files modified:
>>>>trunk/autogen.sh |29 -
>>>>1 files changed, 28 insertions(+), 1 deletions(-)
>>>>
>>>> Modified: trunk/autogen.sh
>>>> ==
>>>> --- trunk/autogen.sh (original)
>>>> +++ trunk/autogen.sh 2007-10-25 10:12:52 EDT (Thu, 25 Oct 2007)
>>>> @@ -1103,6 +1103,32 @@
>>>> unset project project_path framework framework_path component
>>>> component_path
>>>> }
>>>>
>>>> +##
>>>> +#
>>>> +# check_for_svk_checkout - determine whether this is an SVK checkout
>>>> +#
>>>> +# INPUT:
>>>> +#none
>>>> +#
>>>> +# OUTPUT:
>>>> +#none
>>>> +#
>>>> +# SIDE EFFECTS:
>>>> +#
>>>> +##
>>>> +check_for_svk_checkout() {
>>>> +is_svk_checkout=0
>>>> +
>>>> +svk_path=`which svk 2>/dev/null`
>>>> +if test -x "$svk_path"; then
>>>> +top_level_dir="`dirname $0`"
>>>> +svk info $top_level_dir >/dev/null 2>&1
>>>> +if test "$?" = 0 ; then
>>>> +is_svk_checkout=1
>>>> +fi
>>>> +fi
>>>> +
>>>> +}
>>>>
>>>>
>>>> ##
>>>> #
>>>> @@ -1135,7 +1161,8 @@
>>>> echo "[Checking] prerequisites"
>>>>
>>>> # sanity check to make sure user isn't being stupid
>>>> -if test ! -d .svn ; then
>>>> +check_for_svk_checkout
>>>> +if test ! -d .svn -a ! $is_svk_checkout ; then
>>>> cat <>>>
>>>> This doesn't look like a developer copy of Open MPI. You probably do
>>>> not
>>>> ___
>>>> svn mailing list
>>>> s...@open-mpi.org
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/svn
>>>
>>
>>
>>
>>> ___
>>> 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] Fwd: [OMPI svn] svn:open-mpi r16563
George, It looks like we should be checking ~/.svk/local not ~/.svk. Does that do the trick? ~/.svk/local maps to the default "//" depot (created by "svk depotmap --init") which I guess does not need to be setup for all SVK users: $ svk depotmap --list Depot Path // $HOME/.svk/local /openmpi/ .../openmpi So users who have never done the "depotmap --init" command will continue to see the "you probably don't want to run autogen.sh ..." warning. -Ethan On Fri, Oct/26/2007 03:13:03PM, George Bosilca wrote: > Ethan, > > Looks like you have a really old version of svk. Here is the information > about mine: > > svk --version > This is svk, version v2.0.2 (using Subversion bindings 1.4.5) > > And here is what's happens when I "svk info" on a non svk path. > > svk info unstable/ompi-trunk > Repository /Users/bosilca/.svk/local does not exist, create? > (y/n)Interrupted. > > I had to kill it with CTRL+C ... > > Thanks, > george. > > On Oct 26, 2007, at 3:04 PM, Ethan Mallove wrote: > >> George, >> >> For me, SVK says the below on a non-SVK path (then it >> immediately exits): >> >> $ svk info /tmp >> path /tmp is not a checkout path. >> >> $ svk --version >> This is svk, version 1.07. >> >> What is the prompt that SVK gives you? >> >> -Ethan >> >> >> On Fri, Oct/26/2007 02:36:50PM, George Bosilca wrote: >>> Ethan, >>> >>> It only solve half the problem. I do have some svk based >>> directories on my system ... but not all my Open MPI >>> checkouts are svk based. So, it still deadlock for me. >>> >>> george. >>> >>> On Oct 26, 2007, at 2:33 PM, Ethan Mallove wrote: >>> >>>> Whoa! My apologies. I saw the same behavior when I did: >>>> >>>> $ rm -rf ~/.svk >>>> >>>> I think if we check the existence of $HOME/.svk before doing >>>> any svk commands then we should be okay. I did that in >>>> r16586. Does it work for you now? >>>> >>>> -Ethan >>>> >>>> >>>> On Fri, Oct/26/2007 02:02:42PM, George Bosilca wrote: >>>>> This patch break the autogen.sh in the case svk is >>>>> available on the node. I try it on MAC OS X as well as >>>>> Linux boxes, and svk info will try to create the svk if >>>>> the project is not svk based. In fact it ask the user if >>>>> he want to create the svk stuff, but the output is hidden >>>>> by the autogen.sh so it just stay there forever. >>>>> >>>>> Thanks, >>>>> george. >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: emall...@osl.iu.edu >>>>>> Date: October 25, 2007 10:12:53 AM EDT >>>>>> To: s...@open-mpi.org >>>>>> Subject: [OMPI svn] svn:open-mpi r16563 >>>>>> Reply-To: de...@open-mpi.org >>>>>> >>>>>> Author: emallove >>>>>> Date: 2007-10-25 10:12:52 EDT (Thu, 25 Oct 2007) >>>>>> New Revision: 16563 >>>>>> URL: https://svn.open-mpi.org/trac/ompi/changeset/16563 >>>>>> >>>>>> Log: >>>>>> Sanity check for SVK workspace in autogen.sh. >>>>>> >>>>>> Text files modified: >>>>>>trunk/autogen.sh |29 - >>>>>>1 files changed, 28 insertions(+), 1 deletions(-) >>>>>> >>>>>> Modified: trunk/autogen.sh >>>>>> == >>>>>> --- trunk/autogen.sh (original) >>>>>> +++ trunk/autogen.sh 2007-10-25 10:12:52 EDT (Thu, 25 Oct 2007) >>>>>> @@ -1103,6 +1103,32 @@ >>>>>> unset project project_path framework framework_path component >>>>>> component_path >>>>>> } >>>>>> >>>>>> +## >>>>>> +# >>>>>> +# check_for_svk_checkout - determine whether this is an SVK checkout >>>>>> +# >>>>>> +# INPUT: >>
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r16909 (f77_hello compiler error)
Hello,
Is this change (or r16908) causing the below error in the MTT
trivial test (f77_hello)? The error occurs on Solaris and
Linux.
...
NOTICE: Invoking /ws/ompi-tools/SUNWspro/SOS11/bin/f90 -f77 -ftrap=%none
-I/installs/cGmK/install/include/v9 -xarch=amd64 hello.f -o f77_hello
-R/installs/cGmK/install/lib/amd64 -R/opt/mx/lib
-L/installs/cGmK/install/lib/amd64 -lmpi_f77 -lmpi -lopen-rte
-lopen-pal -lsocket -lnsl -lrt -lm
hello.f:
MAIN main:
Undefined first referenced
symbol in file
intercept_extra_state_t_class
/installs/cGmK/install/lib/amd64/libmpi_f77.so
ld: fatal: Symbol referencing errors. No output written to f77_hello
See also http://www.open-mpi.org/mtt/index.php?do_redir=475.
Didn't look that closely here, just noted the line change
involving "intercept_extra_state".
-Ethan
On Sun, Dec/09/2007 07:19:59PM, bosi...@osl.iu.edu wrote:
> Author: bosilca
> Date: 2007-12-09 19:19:58 EST (Sun, 09 Dec 2007)
> New Revision: 16909
> URL: https://svn.open-mpi.org/trac/ompi/changeset/16909
>
> Log:
> Avoid a compiler warning about the function being defined but not
> used when we compile the profiling layer.
>
> Text files modified:
>trunk/ompi/mpi/f77/register_datarep_f.c | 6 +++---
>
>1 files changed, 3 insertions(+), 3 deletions(-)
>
> Modified: trunk/ompi/mpi/f77/register_datarep_f.c
> ==
> --- trunk/ompi/mpi/f77/register_datarep_f.c (original)
> +++ trunk/ompi/mpi/f77/register_datarep_f.c 2007-12-09 19:19:58 EST (Sun,
> 09 Dec 2007)
> @@ -90,6 +90,9 @@
> MPI_Aint *extra_state_f77;
> } intercept_extra_state_t;
>
> +OBJ_CLASS_DECLARATION(intercept_extra_state_t);
> +
> +#if !OMPI_PROFILE_LAYER
> static void intercept_extra_state_constructor(intercept_extra_state_t *obj)
> {
> obj->read_fn_f77 = NULL;
> @@ -98,9 +101,6 @@
> obj->extra_state_f77 = NULL;
> }
>
> -OBJ_CLASS_DECLARATION(intercept_extra_state_t);
> -
> -#if !OMPI_PROFILE_LAYER
> OBJ_CLASS_INSTANCE(intercept_extra_state_t,
> opal_list_item_t,
> intercept_extra_state_constructor, NULL);
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
Re: [OMPI devel] inline asm patch
On Thu, Dec/20/2007 08:50:41AM, Jeff Squyres wrote: > After Ethan's inline assembly patch (to make the > upper-level atomic.h declarations match the lower-level > inline definitions -- if they exist), I've had a problem > with the PGI compiler on Linux. > > I finally tracked down the issue this morning -- it seems > that OMPI_GCC_INLINE_ASSEMBLY is 0 for the PGI compiler. > Hence, none of the assembly routines are inlined. The > logic for the lower layer to say "these functions aren't > inlined" didn't take the value of OMPI_GCC_INLINE_ASSEMBLY > into account, so the upper layer was still prefixing the > declarations with "static inline", which led to linker > problems later. > > The below patch fixes the problem for me, but I wanted to > run it by others before committing because it's fairly > tangled logic (both inline for easy reading and attached > in case my mail client munges the formatting). Can this logic be up-leveled into sys/atomic.h (see below) such that we have it in one atomic.h file instead of nine atomic.h files? This would mean that if a given lower-level /atomic.h file defines a non-GCC-style inline atomic, that file would have to set an OPAL_HAVE_INLINE_* macro, but I don't see any cases like this currently (there is only XLC-style inline assembly in powerpc/atomic.h). Index: opal/include/opal/sys/atomic.h === --- opal/include/opal/sys/atomic.h (revision 17003) +++ opal/include/opal/sys/atomic.h (working copy) @@ -111,19 +111,27 @@ /** * - * Zero these macros in the architecture-specific atomic.h files if we - * need to define their corresponding functions as non-inline (e.g., - * in an opal/asm/base/.asm file). These macros allow us to make - * the signatures of the prototype and definition identical. - * + * Set or unset these macros in the architecture-specific atomic.h + * files if we need to specify them as inline or non-inline + * */ +#if !OMPI_GCC_INLINE_ASSEMBLY +#define OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER 0 +#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 0 +#define OPAL_HAVE_INLINE_ATOMIC_ADD_32 0 +#define OPAL_HAVE_INLINE_ATOMIC_SUB_32 0 +#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 0 +#define OPAL_HAVE_INLINE_ATOMIC_ADD_64 0 +#define OPAL_HAVE_INLINE_ATOMIC_SUB_64 0 +#else #define OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER 1 #define OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 1 -#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 1 #define OPAL_HAVE_INLINE_ATOMIC_ADD_32 1 #define OPAL_HAVE_INLINE_ATOMIC_SUB_32 1 +#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 1 #define OPAL_HAVE_INLINE_ATOMIC_ADD_64 1 #define OPAL_HAVE_INLINE_ATOMIC_SUB_64 1 +#endif /** * -Ethan > > -- > Jeff Squyres > Cisco Systems > > Index: opal/include/opal/sys/ia32/atomic.h > === > --- opal/include/opal/sys/ia32/atomic.h (revision 16997) > +++ opal/include/opal/sys/ia32/atomic.h (working copy) > @@ -10,6 +10,7 @@ > * Copyright (c) 2004-2005 The Regents of the University of California. > * All rights reserved. > * Copyright (c) 2007 Sun Microsystems, Inc. All rights reserverd. > + * Copyright (c) 2007 Cisco Systems, Inc. All rights reserverd. > * $COPYRIGHT$ > * > * Additional copyrights may follow > @@ -51,6 +52,21 @@ > #undef OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 > #define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 0 > > +/* If we don't have GCC inline assembly, then nothing is inline */ > +#if !OMPI_GCC_INLINE_ASSEMBLY > +#undef OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER > +#define OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER 0 > + > +#undef OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 > +#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 0 > + > +#undef OPAL_HAVE_INLINE_ATOMIC_ADD_32 > +#define OPAL_HAVE_INLINE_ATOMIC_ADD_32 0 > + > +#undef OPAL_HAVE_INLINE_ATOMIC_SUB_32 > +#define OPAL_HAVE_INLINE_ATOMIC_SUB_32 0 > +#endif > + > /** > * > * Memory Barriers > Index: opal/include/opal/sys/amd64/atomic.h > === > --- opal/include/opal/sys/amd64/atomic.h (revision 16997) > +++ opal/include/opal/sys/amd64/atomic.h (working copy) > @@ -10,6 +10,7 @@ > * Copyright (c) 2004-2005 The Regents of the University of California. > * All rights reserved. > * Copyright (c) 2007 Sun Microsystems, Inc. All rights reserverd. > + * Copyright (c) 2007 Cisco Systems, Inc. All rights reserverd. > * $COPYRIGHT$ > * > * Additional copyrights may follow > @@ -44,7 +45,18 @@ > > #define OPAL_HAVE_ATOMIC_CMPSET_64 1 > > +/* If we don't have GCC inline assembly, then nothing is inline */ > +#if !OMPI_GCC
[OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
WHAT: Add patch-libtool-for-sun-studio.pl script
WHY:
There are a couple issues with SunStudio and Libtool:
1. The SunStudio libCrun/libCstd C++ libs get linked into Open MPI by
libtool, which can lead to STL incompatibilities on Solaris
2. Libtool uses the wrong linker flags for C++ and Fortran (on Linux Sun
Studio)
Benefits of the fix:
1. Anyone can easily build Open MPI using SunStudio
2. Nightly MTT Linux/SunStudio runs will pass
3. We can remove (most) of the Open MPI SunStudio building FAQ:
http://www.open-mpi.org/faq/?category=building#build-sun-compilers
WHERE: See attached patch; config/patch-libtool-for-sun-studio.pl and
configure.ac
WHEN: Soon
TIMEOUT: Later
One concern is that there's no precedent in Open MPI for patching libtool
*after* configure (we only patch libtool beforehand in autogen.sh). The
problem is that this particular libtool "patch" should only be used in the
case of Sun Studio which is not known until configure-time, and there does
not seem to be a generic patch that we could apply before configure.
-Ethan
Index: configure.ac
===
--- configure.ac(revision 19845)
+++ configure.ac(working copy)
@@ -1356,3 +1361,11 @@
test/datatype/Makefile
])
AC_OUTPUT
+
+# When building with Sun Studio, we need to tweak the libtool script to:
+# 1. Set wl variable so the linker flags work correctly (on Linux)
+# 2. Set postdeps variable to avoid linking libCstd/libCrun C++ libraries
+ompi_patch_libtool_for_sun_studio="config/patch-libtool-for-sun-studio.pl"
+if test "x$ompi_cv_c_compiler_vendor" = "xsun" -a -x
"$ompi_patch_libtool_for_sun_studio"; then
+$ompi_patch_libtool_for_sun_studio
+fi
Index: config/patch-libtool-for-sun-studio.pl
===
--- config/patch-libtool-for-sun-studio.pl (revision 0)
+++ config/patch-libtool-for-sun-studio.pl (revision 0)
@@ -0,0 +1,93 @@
+#!/usr/bin/env perl
+
+use strict;
+use File::Basename;
+use Data::Dumper;
+
+# Grab the name of this script
+my $program = basename($0);
+
+# Call the main subroutine and exit
+&update_libtool_script;
+exit;
+
+sub update_libtool_script {
+my ($file) = @_;
+print("update_libtool_script: got @_\n");
+
+# By default, patch the libtool script in the cwd
+$file = "./libtool" if (! -e $file);
+
+# Keep a backup copy of the file lying around for debugging
+# purposes
+my $cmd = "cp $file $file.orig\n";
+print($cmd);
+system($cmd);
+
+# Read in the libtool script file
+my $contents = Read($file);
+die("Couldn't Read $file!\n") if (!$contents);
+
+my $bad_pattern1 ='(\n# ### BEGIN LIBTOOL TAG CONFIG: FC.*)\n(wl="-Wl,")';
+my $good_pattern1 = "
+# $program has reassigned wl to \"\" because Sun Studio
+# f90 (for Linux) does not pass -Wl values to the GNU linker (/usr/bin/ld)
+wl=\"\"";
+
+my $bad_pattern2 ='(\n# ### BEGIN LIBTOOL TAG CONFIG:
CXX.*)\n(postdeps="(?:-library=Cstd)\s*(?:-library=Crun)?")';
+my $good_pattern2 = "
+# $program has commented out postdeps so that libCstd.so
+# and libCrun.so are not linked in to libmpi_cxx.so. The autogen.sh patch for
+# this same issue was supposed to take care of this, but apparently
+# Autosomething-or-other has usurped that patch and thrown in the bad -library
+# flags.
+postdeps=\"\"
+";
+
+# From perldoc perlre, the "s" modifier in s///s:
+# Treat string as single line. That is, change "." to match any character
+# whatsoever, even a newline, which normally it would not match. Used
+# together, as /ms, they let the "." match any character whatsoever,
+# while still allowing "^" and "$" to match, respectively, just after and
+# just before newlines within the string.
+
+# Grab uname OS string
+my $os = `uname -s`;
+chomp $os;
+if ($os =~ /Linux/i) {
+print("We need to patch $file for libmpi_f90.\n");
+
+# Set wl to "" for f90
+$contents =~ s/$bad_pattern1/$1\n# $2\n$good_pattern1/s;
+}
+
+# Comment this postdeps var out of CXX section
+# postdeps="-library=Cstd -library=Crun"
+print("Patching $file to avoid linking with libCstd and libCrun.\n");
+$contents =~ s/$bad_pattern2/$1\n# $2\n$good_pattern2/s;
+
+# Write changed file out
+Write($file, $contents);
+}
+
+sub Read {
+my ($file) = @_;
+
+my $contents;
+open (INPUT, $file) or warn "Can't
Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
On Wed, Nov/19/2008 10:05:55AM, George Bosilca wrote: > We're still using STL ? I was pretty much sure that we removed this > dependency a while ago ? Open MPI is now set up to use either of Solaris's two versions of STL. The problem is that if libtool links in libCrun/libCstd, then bad things happen if the user code contains code for the other STL version. (Not sure if I got that 100% right.) Dan overhauled Open MPI's handling of STL a while ago (r17448, r17418, r17409, ...). -Ethan > > george. > > On Nov 19, 2008, at 09:11 , Ethan Mallove wrote: > >> >> WHAT: Add patch-libtool-for-sun-studio.pl script >> >> >> WHY: >> >> There are a couple issues with SunStudio and Libtool: >> >>1. The SunStudio libCrun/libCstd C++ libs get linked into Open MPI by >> libtool, which can lead to STL incompatibilities on Solaris >>2. Libtool uses the wrong linker flags for C++ and Fortran (on Linux >> Sun >> Studio) >> >> Benefits of the fix: >> >>1. Anyone can easily build Open MPI using SunStudio >>2. Nightly MTT Linux/SunStudio runs will pass >>3. We can remove (most) of the Open MPI SunStudio building FAQ: >> http://www.open-mpi.org/faq/?category=building#build-sun-compilers >> >> >> WHERE: See attached patch; config/patch-libtool-for-sun-studio.pl and >> configure.ac >> >> >> WHEN: Soon >> >> >> TIMEOUT: Later >> >> >> >> One concern is that there's no precedent in Open MPI for patching libtool >> *after* configure (we only patch libtool beforehand in autogen.sh). The >> problem is that this particular libtool "patch" should only be used in the >> case of Sun Studio which is not known until configure-time, and there does >> not seem to be a generic patch that we could apply before configure. >> >> -Ethan >> ___ >> 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] RFC: Add SunStudio/Libtool helper script for post-configure
On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote: > Hello Ethan, > > * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET: > > There are a couple issues with SunStudio and Libtool: > > Which Libtool version are you using? If not 2.2.2 or newer, then please > retry with 2.2.6. If the problem persists, then we should fix Libtool > rather than patching OpenMPI. That way, other packages benefit from the > fix as well. > I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try 2.2.6. Thanks, Ethan > Thanks, > Ralf > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
On Wed, Nov/19/2008 01:42:55PM, Ethan Mallove wrote: > On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote: > > Hello Ethan, > > > > * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET: > > > There are a couple issues with SunStudio and Libtool: > > > > Which Libtool version are you using? If not 2.2.2 or newer, then please > > retry with 2.2.6. If the problem persists, then we should fix Libtool > > rather than patching OpenMPI. That way, other packages benefit from the > > fix as well. > > > > I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try > 2.2.6. > I'm seeing the same issue with the faulty "wl" Libtool variable in 2.2.6 with Linux SunStudio: ... make[5]: Entering directory `ompi/mpi/f90' /bin/sh ../../../libtool --mode=link f90 -I../../../ompi/include -I../../../ompi/include -M. -I. -I../../../ompi/mpi/f90 -m32 -xO5 -export-dynamic-o libmpi_f90.la -rpath /opt/SUNWhpc/HPC8.1/sun/lib mpi.lo mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo mpi_wtime_f90.lo ../../../ompi/libmpi.la -lnsl -lutil -lm libtool: link: f90 -G .libs/mpi.o .libs/mpi_sizeof.o .libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o -Wl,-rpath -Wl,ompi/.libs -Wl,-rpath -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs -Wl,-rpath -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs -Wl,-rpath -Wl,/opt/SUNWhpc/HPC8.1/sun/lib -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs ../../../ompi/.libs/libmpi.so /tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs/libopen-rte.so opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm -m32 -mt -Wl,-soname -Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0 f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,ompi/.libs passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,orte/.libs passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,opal/.libs passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,/opt/SUNWhpc/HPC8.1/sun/lib passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,-soname passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -Wl,libmpi_f90.so.0 passed to ld, if ld is invoked, ignored otherwise /usr/bin/ld: unrecognized option '-Wl,-rpath' /usr/bin/ld: use the --help option for usage information make[5]: *** [libmpi_f90.la] Error 1 make[5]: Leaving directory `ompi/mpi/f90' make[4]: *** [install-recursive] Error 1 make[4]: Leaving directory `ompi/mpi/f90' make[3]: *** [install] Error 2 make[3]: Leaving directory `ompi/mpi/f90' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `ompi' make[1]: *** [install] Error 2 make[1]: Leaving directory `ompi' make: *** [install-recursive] Error 1 The wl var in auto-generated libtool script should be set to "". Less sure about the Cstd/stlport4 issue, though it does appear from the below thread that the issue was already tackled at some point: http://lists.gnu.org/archive/html/libtool/2008-02/msg00024.html The thread says the Cstd/stlport4 issue was fixed in 2006. -Ethan > Thanks, > Ethan > > > > Thanks, > > Ralf > > ___ > > 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] RFC: Add SunStudio/Libtool helper script for post-configure
On Wed, Nov/19/2008 03:24:16PM, Ethan Mallove wrote: > On Wed, Nov/19/2008 01:42:55PM, Ethan Mallove wrote: > > On Wed, Nov/19/2008 05:12:03PM, Ralf Wildenhues wrote: > > > Hello Ethan, > > > > > > * Ethan Mallove wrote on Wed, Nov 19, 2008 at 04:11:23PM CET: > > > > There are a couple issues with SunStudio and Libtool: > > > > > > Which Libtool version are you using? If not 2.2.2 or newer, then please > > > retry with 2.2.6. If the problem persists, then we should fix Libtool > > > rather than patching OpenMPI. That way, other packages benefit from the > > > fix as well. > > > > > > > I'm using 2.2 (for Solaris) and 2.1b (for Linux). I'll try > > 2.2.6. > > > > I'm seeing the same issue with the faulty "wl" Libtool > variable in 2.2.6 with Linux SunStudio: > > ... > make[5]: Entering directory `ompi/mpi/f90' > /bin/sh ../../../libtool --mode=link f90 -I../../../ompi/include > -I../../../ompi/include -M. -I. -I../../../ompi/mpi/f90 -m32 -xO5 > -export-dynamic-o libmpi_f90.la -rpath /opt/SUNWhpc/HPC8.1/sun/lib mpi.lo > mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo > mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo > mpi_wtime_f90.lo ../../../ompi/libmpi.la -lnsl -lutil -lm > libtool: link: f90 -G .libs/mpi.o .libs/mpi_sizeof.o > .libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o > .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o > .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o -Wl,-rpath -Wl,ompi/.libs > -Wl,-rpath > -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs > -Wl,-rpath > -Wl,/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs > -Wl,-rpath -Wl,/opt/SUNWhpc/HPC8.1/sun/lib > -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs > > -L/tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/opal/.libs > ../../../ompi/.libs/libmpi.so > /tmp/mtt-scratch-patch-libtool-for-sun-studio/mpi-install/HFfN/src/ompi-ct8.1-v1.3-sandbox/orte/.libs/libopen-rte.so > opal/.libs/libopen-pal.so -ldl -lnsl -lutil -lm -m32 -mt -Wl,-soname > -Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0 > f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored > otherwise > f90: Warning: Option -Wl,ompi/.libs passed to ld, if ld is invoked, ignored > otherwise > f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored > otherwise > f90: Warning: Option -Wl,orte/.libs passed to ld, if ld is invoked, > ignored otherwise > f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored > otherwise > f90: Warning: Option -Wl,opal/.libs passed to ld, if ld is invoked, > ignored otherwise > f90: Warning: Option -Wl,-rpath passed to ld, if ld is invoked, ignored > otherwise > f90: Warning: Option -Wl,/opt/SUNWhpc/HPC8.1/sun/lib passed to ld, if ld > is invoked, ignored otherwise > f90: Warning: Option -Wl,-soname passed to ld, if ld is invoked, ignored > otherwise > f90: Warning: Option -Wl,libmpi_f90.so.0 passed to ld, if ld is invoked, > ignored otherwise > /usr/bin/ld: unrecognized option '-Wl,-rpath' > /usr/bin/ld: use the --help option for usage information > make[5]: *** [libmpi_f90.la] Error 1 > make[5]: Leaving directory `ompi/mpi/f90' > make[4]: *** [install-recursive] Error 1 > make[4]: Leaving directory `ompi/mpi/f90' > make[3]: *** [install] Error 2 > make[3]: Leaving directory `ompi/mpi/f90' > make[2]: *** [install-recursive] Error 1 > make[2]: Leaving directory `ompi' > make[1]: *** [install] Error 2 > make[1]: Leaving directory `ompi' > make: *** [install-recursive] Error 1 > > The wl var in auto-generated libtool script should be set to > "". I think I found a potential problem. I see this in configure: case `$CC -V 2>&1 | sed 5q` in *Sun\ C*) # Sun C 5.9 lt_prog_compiler_pic='-KPIC' lt_prog_compiler_static='-Bstatic' lt_prog_compiler_wl='-Wl,' ;; *Sun\ F*) # Sun Fortran 8.3 passes all unrecognized flags to the linker lt_prog_compiler_pic='-KPIC' lt_prog_compiler_static='-Bstatic' lt_prog_compiler_wl='' ;; esac ;; The above appears to be looking for a Fortran version string from the C compiler, but it wouldn't match our version string an
Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
On Thu, Nov/20/2008 07:00:31PM, Ralf Wildenhues wrote: > Our previous mails overlapped, sorry about that. > > * Ethan Mallove wrote on Thu, Nov 20, 2008 at 06:52:09PM CET: > > > > The above appears to be looking for a Fortran version string from the > > C compiler, but it wouldn't match our version string anyway: > > > > $ f90 -V > > f90: Sun Ceres Fortran 95 8.3 SunOS_sparc 2008/01/28 > > Ah, ok. Please try the patch below instead of yours, thanks. Your patch seems to work, though I get this: libtool: Version mismatch error. This is libtool 2.2.7a, but the libtool: definition of this LT_INIT comes from libtool 2.2.6. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.7a libtool: and run autoconf again. I take it the above error will occur if I have two different libtools in my PATH? This comment could be a little misleading because the same is true for Sun Fortran 8.1 and 8.2: # Sun Fortran 8.3 passes all unrecognized flags to the linker I don't know of a version of Sun Fortran that accepts -Wl the way GNU Fortran does. I will let you know if I find one. > Do you mind being added to libtool/THANKS (includes email address)? I do not mind. > > I'm still running into the Cstd/stlport4 issue with 2.2.6. That is, > > this line appears in the libtool script: > > > > postdeps="-library=Cstd -library=Crun" > > Do you have the string " -library=stlport4 " in $CXX $CXXFLAGS? > If not, then how can Libtool detect that you use stlport? Ok. When I use -library=stlport4, I get libstlport linked to libmpi_cxx, instead of libCstd. Doesn't that then lock the user into having to use stlport4 when we want them to be able to use either Cstd or stlport4? Thanks, Ethan > > Thanks, > Ralf > > * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [ linux ]: Also > match `Sun Ceres Fortran' compiler; reorder with C compiler > matching. > * THANKS: Update. > Report by Ethan Mallove. > > diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 > index 7fbf965..d90c4f4 100644 > --- a/libltdl/m4/libtool.m4 > +++ b/libltdl/m4/libtool.m4 > @@ -3947,17 +3947,17 @@ m4_if([$1], [CXX], [ > ;; >*) > case `$CC -V 2>&1 | sed 5q` in > - *Sun\ C*) > - # Sun C 5.9 > + *Sun\ F* | *Sun*Fortran*) > + # Sun Fortran 8.3 passes all unrecognized flags to the linker > _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' > _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' > - _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' > + _LT_TAGVAR(lt_prog_compiler_wl, $1)='' > ;; > - *Sun\ F*) > - # Sun Fortran 8.3 passes all unrecognized flags to the linker > + *Sun\ C*) > + # Sun C 5.9 > _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' > _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' > - _LT_TAGVAR(lt_prog_compiler_wl, $1)='' > + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' > ;; > esac > ;; > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
On Fri, Nov/21/2008 01:02:12PM, Ralf Wildenhues wrote: > Hello Ethan, all, > > * Ethan Mallove wrote on Thu, Nov 20, 2008 at 10:33:08PM CET: > > On Thu, Nov/20/2008 07:00:31PM, Ralf Wildenhues wrote: > > > > > > Ah, ok. Please try the patch below instead of yours, thanks. > > > > Your patch seems to work, though I get this: > > > >libtool: Version mismatch error. This is libtool 2.2.7a, but the > >libtool: definition of this LT_INIT comes from libtool 2.2.6. > >libtool: You should recreate aclocal.m4 with macros from libtool 2.2.7a > >libtool: and run autoconf again. > > > > I take it the above error will occur if I have two different libtools > > in my PATH? > > No. That means the macro files that were picked up were from Libtool > 2.2.6, while the ltmain.sh file is from 2.2.7a. > > > This comment could be a little misleading because the same is true for > > Sun Fortran 8.1 and 8.2: > > > > # Sun Fortran 8.3 passes all unrecognized flags to the linker > > OK. I think we simply didn't have any other version to test at the time > this was written. We usually list the version somewhere so we can check > for version-specific issues, should they later show up. > > I will update the comment to list '8.1 through 8.3', when I commit your > patch (sometime this weekend); thanks for testing it. > > > I don't know of a version of Sun Fortran that accepts -Wl the way GNU > > Fortran does. I will let you know if I find one. > > Thanks. > > > > > I'm still running into the Cstd/stlport4 issue with 2.2.6. That is, > > > > this line appears in the libtool script: > > > > > > > > postdeps="-library=Cstd -library=Crun" > > > > > > Do you have the string " -library=stlport4 " in $CXX $CXXFLAGS? > > > If not, then how can Libtool detect that you use stlport? > > > > Ok. When I use -library=stlport4, I get libstlport linked to > > libmpi_cxx, instead of libCstd. Doesn't that then lock the user into > > having to use stlport4 when we want them to be able to use either Cstd > > or stlport4? > > Hmm, yes, it does. It is a bit of a problem to let libtool avoid either > standard C++ library in general: with shared libraries or even > dlopen'able modules, this can result in undefined symbols at run time. > > As the code is currently written in libtool.m4, there is an undocumented > way which you can use to get the effects of adding neither library: set > solaris_use_stlport4=yes. You can use this, either as argument to > configure, or set it inside configure.ac (or a macro) so that it is > expanded before AC_PROG_LIBTOOL. > > However, as it is undocumented, there is no guarantee that it will > continue to work indefinitely. What Libtool should instead do future is > provide some configure flag to allow to specify that no C++ standard > library is to be linked in by default. That would help for a couple of > different setups with other compilers as well. IMHO OpenMPI can use > the solaris_use_stlport4=yes until such a functionality is in place. Nice. This workaround works. I don't suppose there's a similar workaround to unset "wl" in the FC libtool section? If not, I think we still need the heinous post-configure workaround script. Otherwise, since there won't be a stable Libtool that contains the Sun Fortran fix for a while, I propose the attached patch. Thanks, Ethan > > Cheers, and thanks, > Ralf > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel Index: configure.ac === --- configure.ac(revision 19845) +++ configure.ac(working copy) @@ -1071,6 +1076,12 @@ ompi_show_subtitle "Libtool configuration" +# Use the undocumented solaris_use_stlport4 libtool variable to turn off any +# Cstd/stlport4 linkage. This allows Open MPI to be C++ STL agnostic. +if test "x$ompi_cv_c_compiler_vendor" = "xsun"; then +solaris_use_stlport4="yes" +fi + dnl Not all versions of LT set the PACKAGE_VERSION m4_ifdef([LT_PACKAGE_VERSION], [], [m4_define([LT_PACKAGE_VERSION], [1.5.22])]) @@ -1356,3 +1367,10 @@ test/datatype/Makefile ]) AC_OUTPUT + +# Fix libtool script bug that passes -Wl to f90, which Sun f90 does not understand. +# (This can be removed if using Libtool 2.2.7 or higher) +ompi_patch_libtool_for_sun_studio="config/patch-libtool-for-sun-studio.pl" +if test "x$ompi_cv_c_compiler_vendor" = "xsun" -a -x "$
Re: [OMPI devel] RFC: Add SunStudio/Libtool helper script for post-configure
On Sun, Nov/23/2008 09:19:12AM, Ralf Wildenhues wrote: > * Ethan Mallove wrote on Fri, Nov 21, 2008 at 09:01:56PM CET: > > On Fri, Nov/21/2008 01:02:12PM, Ralf Wildenhues wrote: > > > IMHO OpenMPI can use > > > the solaris_use_stlport4=yes until such a functionality is in place. > > > > Nice. This workaround works. I don't suppose there's a similar > > workaround to unset "wl" in the FC libtool section? If not, I think we > > still need the heinous post-configure workaround script. Otherwise, > > since there won't be a stable Libtool that contains the Sun Fortran > > fix for a while, I propose the attached patch. > > While I suppose your patch works, I think in similar situations, OpenMPI > has resorted to patching input files to configure (like aclocal.m4 or > ltmain.sh). Search autogen.sh for instances of 'patch'. > I think I got it. I patch libtool.m4 in autogen.sh after libtoolize creates libtool.m4. How is the patch now? -Ethan > (This is merely an observation; I am not an OpenMPI developer.) > > Cheers, > Ralf > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel Index: configure.ac === --- configure.ac(revision 19845) +++ configure.ac(working copy) @@ -1071,6 +1076,12 @@ ompi_show_subtitle "Libtool configuration" +# Use the undocumented solaris_use_stlport4 libtool variable to turn off any +# Cstd/stlport4 linkage. This allows Open MPI to be C++ STL agnostic. +if test "x$ompi_cv_c_compiler_vendor" = "xsun"; then +solaris_use_stlport4="yes" +fi + dnl Not all versions of LT set the PACKAGE_VERSION m4_ifdef([LT_PACKAGE_VERSION], [], [m4_define([LT_PACKAGE_VERSION], [1.5.22])]) Index: autogen.sh === --- autogen.sh (revision 19845) +++ autogen.sh (working copy) @@ -541,6 +541,12 @@ aclocal.m4 > aclocal.m4.new cp aclocal.m4.new aclocal.m4 rm -f aclocal.m4.new + +# This patch fixes a bug in Libtool's detection of the Sun Studio +# Fortran compiler. See the below e-mail thread for more details: +# http://www.open-mpi.org/community/lists/devel/2008/11/4920.php +echo " ++ patching for Sun Studio Fortran compilers" +patch -N -p0 < config/lt-sun-fortran.diff > /dev/null 2>&1 fi run_and_check $ompi_autoconf Index: config/lt-sun-fortran.diff === --- config/lt-sun-fortran.diff (revision 0) +++ config/lt-sun-fortran.diff (revision 0) @@ -0,0 +1,26 @@ +--- config/libtool.m4.orig config/libtool.m4 +@@ -3947,17 +3947,17 @@ m4_if([$1], [CXX], [ + ;; + *) + case `$CC -V 2>&1 | sed 5q` in +- *Sun\ C*) +-# Sun C 5.9 ++ *Sun\ F* | *Sun*Fortran*) ++# Sun Fortran 8.3 passes all unrecognized flags to the linker + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +-_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' ++_LT_TAGVAR(lt_prog_compiler_wl, $1)='' + ;; +- *Sun\ F*) +-# Sun Fortran 8.3 passes all unrecognized flags to the linker ++ *Sun\ C*) ++# Sun C 5.9 + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +-_LT_TAGVAR(lt_prog_compiler_wl, $1)='' ++_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + ;; + esac + ;;
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r20003 (Solaris malloc.h issue)
Hi Patrick,
r20003 seems to break MX support on Solaris.
$ cd ompi/mca/common/mx
$ make
...
"/usr/include/malloc.h", line 46: syntax error before or at: (
"/usr/include/malloc.h", line 47: syntax error before or at: (
"/usr/include/malloc.h", line 48: syntax error before or at: (
"/usr/include/malloc.h", line 48: cannot have void object: size_t
"/usr/include/malloc.h", line 48: identifier redeclared: size_t
... <4000 more lines of compiler errors> ...
The below patch makes it so opal/util/malloc.h is used instead of
/usr/include/malloc.h and the compiler errors go away. (I also needed
to include errno.h.) Would this be okay to do?
diff -r 347f52a3713f ompi/mca/common/mx/common_mx.c
--- ompi/mca/common/mx/common_mx.c
+++ ompi/mca/common/mx/common_mx.c
@@ -23,9 +23,8 @@
#include "ompi/constants.h"
#include "common_mx.h"
-#ifdef HAVE_MALLOC_H
-#include
-#endif
+#include
+#include "opal/util/malloc.h"
#include "opal/memoryhooks/memory.h"
#include "opal/mca/base/mca_base_param.h"
#include "ompi/runtime/params.h"
I tested the above on Solaris and Linux with SunStudio.
Regards,
Ethan
On Fri, Nov/14/2008 11:17:59PM, patr...@osl.iu.edu wrote:
> Author: patrick
> Date: 2008-11-14 23:17:58 EST (Fri, 14 Nov 2008)
> New Revision: 20003
> URL: https://svn.open-mpi.org/trac/ompi/changeset/20003
>
> Log:
> Define a "fake" mpool to provide a memory release callback for the
> memory hooks (munmap) and initialize the mallopt component, and
> nothing else.
> Use this mpool in the MX common initialization, supporting both BTL
> and MTL. Automatically set the MX_RCACHE environment variable to
> enable registration cache in MX.
>
> Tested with success for munmap() and large free().
>
>
> Added:
>trunk/ompi/mca/mpool/fake/
>trunk/ompi/mca/mpool/fake/Makefile.am
>trunk/ompi/mca/mpool/fake/configure.params
>trunk/ompi/mca/mpool/fake/mpool_fake.h
>trunk/ompi/mca/mpool/fake/mpool_fake_component.c
>trunk/ompi/mca/mpool/fake/mpool_fake_module.c
> Text files modified:
>trunk/ompi/mca/common/mx/common_mx.c |56
> +++
>1 files changed, 55 insertions(+), 1 deletions(-)
>
> Modified: trunk/ompi/mca/common/mx/common_mx.c
> ==
> --- trunk/ompi/mca/common/mx/common_mx.c (original)
> +++ trunk/ompi/mca/common/mx/common_mx.c 2008-11-14 23:17:58 EST (Fri,
> 14 Nov 2008)
> @@ -9,6 +9,8 @@
> * University of Stuttgart. All rights reserved.
> * Copyright (c) 2004-2006 The Regents of the University of California.
> * All rights reserved.
> + * Copyright (c) 2008 Myricom. All rights reserved.
> + *
> * $COPYRIGHT$
> *
> * Additional copyrights may follow
> @@ -21,11 +23,29 @@
> #include "ompi/constants.h"
> #include "common_mx.h"
>
> +#ifdef HAVE_MALLOC_H
> +#include
> +#endif
> +#include "opal/memoryhooks/memory.h"
> +#include "opal/mca/base/mca_base_param.h"
> +#include "ompi/runtime/params.h"
> +#include "ompi/mca/mpool/mpool.h"
> +#include "ompi/mca/mpool/base/base.h"
> +#include "ompi/mca/mpool/fake/mpool_fake.h"
> +
> +
> +int mx__regcache_clean(void *ptr, size_t size);
> +
> static int ompi_common_mx_initialize_ref_cnt = 0;
> +static mca_mpool_base_module_t *ompi_common_mx_fake_mpool = 0;
> +
> int
> ompi_common_mx_initialize(void)
> {
> mx_return_t mx_return;
> +struct mca_mpool_base_resources_t mpool_resources;
> +int index, value;
> +
> ompi_common_mx_initialize_ref_cnt++;
>
> if(ompi_common_mx_initialize_ref_cnt == 1) {
> @@ -35,7 +55,37 @@
> * library does not exit the application.
> */
> mx_set_error_handler(MX_ERRORS_RETURN);
> -
> +
> + /* If we have a memory manager available, and
> +mpi_leave_pinned == -1, then set mpi_leave_pinned to 1.
> +
> +We have a memory manager if:
> +- we have both FREE and MUNMAP support
> +- we have MUNMAP support and the linux mallopt */
> + value = opal_mem_hooks_support_level();
> + if (((value & (OPAL_MEMORY_FREE_SUPPORT | OPAL_MEMORY_MUNMAP_SUPPORT))
> + == (OPAL_MEMORY_FREE_SUPPORT | OPAL_MEMORY_MUNMAP_SUPPORT))
> + || ((value & OPAL_MEMORY_MUNMAP_SUPPORT) &&
> + OMPI_MPOOL_BASE_HAVE_LINUX_MALLOPT)) {
> + index = mca_base_param_find("mpi", NULL, "leave_pinned");
> + if (index >= 0)
> +if ((mca_base_param_lookup_int(index, &value) == OPAL_SUCCESS)
> + && (value == -1)) {
> +
> + ompi_mpi_leave_pinned = 1;
> + setenv("MX_RCACHE", "2", 1);
> + mpool_resources.regcache_clean = mx__regcache_clean;
> + ompi_common_mx_fake_mpool =
> + mca_mpool_base_module_create("fake", NULL, &mpool_resources);
> + if (!ompi_common_mx_fake_mpool) {
> + omp
