Re: [OMPI devel] Duplicated modex issue.
Yeah, that won't work. The id's cannot be reused, so you'd have to assign a
different one in each case.
On Dec 20, 2012, at 9:12 AM, Victor Kocheganov
wrote:
> In every 'modex' block I use coll->id = orte_process_info.peer_modex; id
> and in every 'barrier' block I use coll->id =
> orte_process_info.peer_init_barrier; id.
>
> P.s. In general (as I wrote in first letter), I use 'modex' term for
> following code:
> coll = OBJ_NEW(orte_grpcomm_collective_t);
> coll->id = orte_process_info.peer_modex;
> if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(coll))) {
> error = "orte_grpcomm_modex failed";
> goto error;
> }
> /* wait for modex to complete - this may be moved anywhere in mpi_init
> * so long as it occurs prior to calling a function that needs
> * the modex info!
> */
> while (coll->active) {
> opal_progress(); /* block in progress pending events */
> }
> OBJ_RELEASE(coll);
>
> and 'barrier' for this:
>
> coll = OBJ_NEW(orte_grpcomm_collective_t);
> coll->id = orte_process_info.peer_init_barrier;
> if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(coll))) {
> error = "orte_grpcomm_barrier failed";
> goto error;
> }
> /* wait for barrier to complete */
> while (coll->active) {
> opal_progress(); /* block in progress pending events */
> }
> OBJ_RELEASE(coll);
>
> On Thu, Dec 20, 2012 at 8:57 PM, Ralph Castain wrote:
>
> On Dec 20, 2012, at 8:29 AM, Victor Kocheganov
> wrote:
>
>> Thanks for fast answer, Ralph.
>>
>> In my example I use different collective objects. I mean in every mentioned
>> block I call coll = OBJ_NEW(orte_grpcomm_collective_t);
>> and OBJ_RELEASE(coll); , so all the grpcomm operations use unique collective
>> object.
>
> How are the procs getting the collective id for those new calls? They all
> have to match
>
>>
>>
>> On Thu, Dec 20, 2012 at 7:48 PM, Ralph Castain wrote:
>> Absolutely it will hang as the collective object passed into any grpcomm
>> operation (modex or barrier) is only allowed to be used once - any attempt
>> to reuse it will fail.
>>
>>
>> On Dec 20, 2012, at 6:57 AM, Victor Kocheganov
>> wrote:
>>
>>> Hi.
>>>
>>> I have an issue with understanding ompi_mpi_init() logic. Could you please
>>> tell me if you have any guesses about following behavior.
>>>
>>> I wonder if I understand ringh, there is a block in ompi_mpi_init()
>>> function for exchanging procs information between processes (denote this
>>> block 'modex'):
>>> coll = OBJ_NEW(orte_grpcomm_collective_t);
>>> coll->id = orte_process_info.peer_modex;
>>> if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(coll))) {
>>> error = "orte_grpcomm_modex failed";
>>> goto error;
>>> }
>>> /* wait for modex to complete - this may be moved anywhere in mpi_init
>>> * so long as it occurs prior to calling a function that needs
>>> * the modex info!
>>> */
>>> while (coll->active) {
>>> opal_progress(); /* block in progress pending events */
>>> }
>>> OBJ_RELEASE(coll);
>>> and several instructions after this there is a block for processes
>>> synchronization (denote this block 'barrier'):
>>> coll = OBJ_NEW(orte_grpcomm_collective_t);
>>> coll->id = orte_process_info.peer_init_barrier;
>>> if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(coll))) {
>>> error = "orte_grpcomm_barrier failed";
>>> goto error;
>>> }
>>> /* wait for barrier to complete */
>>> while (coll->active) {
>>> opal_progress(); /* block in progress pending events */
>>> }
>>> OBJ_RELEASE(coll);
>>> So, initially ompi_mpi_init() has following structure:
>>> ...
>>> 'modex' block;
>>> ...
>>> 'barrier' block;
>>> ...
>>> I made several experiments with this code and the following one is of
>>> interest: if I add sequence of two additional blocks, 'barrier' and
>>> 'modex', right after 'modex' block, then ompi_mpi_init() hangs in
>>> opal_progress() of the last 'modex' block.
>>> ...
>>> 'modex' block;
>>> 'barrier' block;
>>> 'modex' block; <- hangs
>>> ...
>>> 'barrier' block;
>>> ...
>>> Thanks,
>>> Victor Kocheganov.
>>> ___
>>> 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
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cg
Re: [OMPI devel] Duplicated modex issue.
In every 'modex' block I use coll->id = orte_process_info.peer_modex; id
and in every 'barrier' block I use coll->id = orte_process_info.peer_init_
barrier; id.
P.s. In general (as I wrote in first letter), I use 'modex' term for
following code:
coll = OBJ_NEW(orte_grpcomm_collective_t);
coll->id = orte_process_info.peer_modex;
if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(coll))) {
error = "orte_grpcomm_modex failed";
goto error;
}
/* wait for modex to complete - this may be moved anywhere in mpi_init
* so long as it occurs prior to calling a function that needs
* the modex info!
*/
while (coll->active) {
opal_progress(); /* block in progress pending events */
}
OBJ_RELEASE(coll);
and 'barrier' for this:
coll = OBJ_NEW(orte_grpcomm_collective_t);
coll->id = orte_process_info.peer_init_barrier;
if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(coll))) {
error = "orte_grpcomm_barrier failed";
goto error;
}
/* wait for barrier to complete */
while (coll->active) {
opal_progress(); /* block in progress pending events */
}
OBJ_RELEASE(coll);
On Thu, Dec 20, 2012 at 8:57 PM, Ralph Castain wrote:
>
> On Dec 20, 2012, at 8:29 AM, Victor Kocheganov <
> victor.kochega...@itseez.com> wrote:
>
> Thanks for fast answer, Ralph.
>
> In my example I use different collective objects. I mean in every
> mentioned block I call *coll = OBJ_NEW(orte_grpcomm_**collective_t);*
> and *OBJ_RELEASE(coll);* , so all the grpcomm operations use unique
> collective object.
>
>
> How are the procs getting the collective id for those new calls? They all
> have to match
>
>
>
> On Thu, Dec 20, 2012 at 7:48 PM, Ralph Castain wrote:
>
>> Absolutely it will hang as the collective object passed into any grpcomm
>> operation (modex or barrier) is only allowed to be used once - any attempt
>> to reuse it will fail.
>>
>>
>> On Dec 20, 2012, at 6:57 AM, Victor Kocheganov <
>> victor.kochega...@itseez.com> wrote:
>>
>> Hi.
>>
>> I have an issue with understanding *ompi_mpi_init() *logic. Could you
>> please tell me if you have any guesses about following behavior.
>>
>> I wonder if I understand ringh, there is a block in *ompi_mpi_init()
>> *function
>> for exchanging procs information between processes (denote this block
>> 'modex'):
>>
>> coll = OBJ_NEW(orte_grpcomm_collective_t);
>> coll->id = orte_process_info.peer_modex;
>> if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(coll))) {
>> error = "orte_grpcomm_modex failed";
>> goto error;
>> }
>> /* wait for modex to complete - this may be moved anywhere in mpi_init
>> * so long as it occurs prior to calling a function that needs
>> * the modex info!
>> */
>> while (coll->active) {
>> opal_progress(); /* block in progress pending events */
>> }
>> OBJ_RELEASE(coll);
>>
>> and several instructions after this there is a block for processes
>> synchronization (denote this block 'barrier'):
>>
>> coll = OBJ_NEW(orte_grpcomm_collective_t);
>> coll->id = orte_process_info.peer_init_barrier;
>> if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(coll))) {
>> error = "orte_grpcomm_barrier failed";
>> goto error;
>> }
>> /* wait for barrier to complete */
>> while (coll->active) {
>> opal_progress(); /* block in progress pending events */
>> }
>> OBJ_RELEASE(coll);
>>
>> So,* *initially* **ompi_mpi_init()* has following structure:
>>
>> ...
>> 'modex' block;
>> ...
>> 'barrier' block;
>> ...
>>
>> I made several experiments with this code and the following one is of
>> interest: if I add sequence of two additional blocks, 'barrier' and
>> 'modex', right after 'modex' block, then* **ompi_mpi_init() *hangs in *
>> opal_progress()* of the last 'modex' block.
>>
>> ...
>> 'modex' block;
>> 'barrier' block;
>> 'modex' block; <- hangs
>> ...
>> 'barrier' block;
>> ...
>>
>> Thanks,
>> Victor Kocheganov.
>> ___
>> 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
>
Re: [OMPI devel] Duplicated modex issue.
On Dec 20, 2012, at 8:29 AM, Victor Kocheganov
wrote:
> Thanks for fast answer, Ralph.
>
> In my example I use different collective objects. I mean in every mentioned
> block I call coll = OBJ_NEW(orte_grpcomm_collective_t);
> and OBJ_RELEASE(coll); , so all the grpcomm operations use unique collective
> object.
How are the procs getting the collective id for those new calls? They all have
to match
>
>
> On Thu, Dec 20, 2012 at 7:48 PM, Ralph Castain wrote:
> Absolutely it will hang as the collective object passed into any grpcomm
> operation (modex or barrier) is only allowed to be used once - any attempt to
> reuse it will fail.
>
>
> On Dec 20, 2012, at 6:57 AM, Victor Kocheganov
> wrote:
>
>> Hi.
>>
>> I have an issue with understanding ompi_mpi_init() logic. Could you please
>> tell me if you have any guesses about following behavior.
>>
>> I wonder if I understand ringh, there is a block in ompi_mpi_init() function
>> for exchanging procs information between processes (denote this block
>> 'modex'):
>> coll = OBJ_NEW(orte_grpcomm_collective_t);
>> coll->id = orte_process_info.peer_modex;
>> if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(coll))) {
>> error = "orte_grpcomm_modex failed";
>> goto error;
>> }
>> /* wait for modex to complete - this may be moved anywhere in mpi_init
>> * so long as it occurs prior to calling a function that needs
>> * the modex info!
>> */
>> while (coll->active) {
>> opal_progress(); /* block in progress pending events */
>> }
>> OBJ_RELEASE(coll);
>> and several instructions after this there is a block for processes
>> synchronization (denote this block 'barrier'):
>> coll = OBJ_NEW(orte_grpcomm_collective_t);
>> coll->id = orte_process_info.peer_init_barrier;
>> if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(coll))) {
>> error = "orte_grpcomm_barrier failed";
>> goto error;
>> }
>> /* wait for barrier to complete */
>> while (coll->active) {
>> opal_progress(); /* block in progress pending events */
>> }
>> OBJ_RELEASE(coll);
>> So, initially ompi_mpi_init() has following structure:
>> ...
>> 'modex' block;
>> ...
>> 'barrier' block;
>> ...
>> I made several experiments with this code and the following one is of
>> interest: if I add sequence of two additional blocks, 'barrier' and 'modex',
>> right after 'modex' block, then ompi_mpi_init() hangs in opal_progress() of
>> the last 'modex' block.
>> ...
>> 'modex' block;
>> 'barrier' block;
>> 'modex' block; <- hangs
>> ...
>> 'barrier' block;
>> ...
>> Thanks,
>> Victor Kocheganov.
>> ___
>> 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] Duplicated modex issue.
Thanks for fast answer, Ralph.
In my example I use different collective objects. I mean in every mentioned
block I call *coll = OBJ_NEW(orte_grpcomm_**collective_t);*
and *OBJ_RELEASE(coll);* , so all the grpcomm operations use unique
collective object.
On Thu, Dec 20, 2012 at 7:48 PM, Ralph Castain wrote:
> Absolutely it will hang as the collective object passed into any grpcomm
> operation (modex or barrier) is only allowed to be used once - any attempt
> to reuse it will fail.
>
>
> On Dec 20, 2012, at 6:57 AM, Victor Kocheganov <
> victor.kochega...@itseez.com> wrote:
>
> Hi.
>
> I have an issue with understanding *ompi_mpi_init() *logic. Could you
> please tell me if you have any guesses about following behavior.
>
> I wonder if I understand ringh, there is a block in *ompi_mpi_init() *function
> for exchanging procs information between processes (denote this block
> 'modex'):
>
> coll = OBJ_NEW(orte_grpcomm_collective_t);
> coll->id = orte_process_info.peer_modex;
> if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(coll))) {
> error = "orte_grpcomm_modex failed";
> goto error;
> }
> /* wait for modex to complete - this may be moved anywhere in mpi_init
> * so long as it occurs prior to calling a function that needs
> * the modex info!
> */
> while (coll->active) {
> opal_progress(); /* block in progress pending events */
> }
> OBJ_RELEASE(coll);
>
> and several instructions after this there is a block for processes
> synchronization (denote this block 'barrier'):
>
> coll = OBJ_NEW(orte_grpcomm_collective_t);
> coll->id = orte_process_info.peer_init_barrier;
> if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(coll))) {
> error = "orte_grpcomm_barrier failed";
> goto error;
> }
> /* wait for barrier to complete */
> while (coll->active) {
> opal_progress(); /* block in progress pending events */
> }
> OBJ_RELEASE(coll);
>
> So,* *initially* **ompi_mpi_init()* has following structure:
>
> ...
> 'modex' block;
> ...
> 'barrier' block;
> ...
>
> I made several experiments with this code and the following one is of
> interest: if I add sequence of two additional blocks, 'barrier' and
> 'modex', right after 'modex' block, then* **ompi_mpi_init() *hangs in *
> opal_progress()* of the last 'modex' block.
>
> ...
> 'modex' block;
> 'barrier' block;
> 'modex' block; <- hangs
> ...
> 'barrier' block;
> ...
>
> Thanks,
> Victor Kocheganov.
> ___
> 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] Duplicated modex issue.
Absolutely it will hang as the collective object passed into any grpcomm
operation (modex or barrier) is only allowed to be used once - any attempt to
reuse it will fail.
On Dec 20, 2012, at 6:57 AM, Victor Kocheganov
wrote:
> Hi.
>
> I have an issue with understanding ompi_mpi_init() logic. Could you please
> tell me if you have any guesses about following behavior.
>
> I wonder if I understand ringh, there is a block in ompi_mpi_init() function
> for exchanging procs information between processes (denote this block
> 'modex'):
> coll = OBJ_NEW(orte_grpcomm_collective_t);
> coll->id = orte_process_info.peer_modex;
> if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(coll))) {
> error = "orte_grpcomm_modex failed";
> goto error;
> }
> /* wait for modex to complete - this may be moved anywhere in mpi_init
> * so long as it occurs prior to calling a function that needs
> * the modex info!
> */
> while (coll->active) {
> opal_progress(); /* block in progress pending events */
> }
> OBJ_RELEASE(coll);
> and several instructions after this there is a block for processes
> synchronization (denote this block 'barrier'):
> coll = OBJ_NEW(orte_grpcomm_collective_t);
> coll->id = orte_process_info.peer_init_barrier;
> if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(coll))) {
> error = "orte_grpcomm_barrier failed";
> goto error;
> }
> /* wait for barrier to complete */
> while (coll->active) {
> opal_progress(); /* block in progress pending events */
> }
> OBJ_RELEASE(coll);
> So, initially ompi_mpi_init() has following structure:
> ...
> 'modex' block;
> ...
> 'barrier' block;
> ...
> I made several experiments with this code and the following one is of
> interest: if I add sequence of two additional blocks, 'barrier' and 'modex',
> right after 'modex' block, then ompi_mpi_init() hangs in opal_progress() of
> the last 'modex' block.
> ...
> 'modex' block;
> 'barrier' block;
> 'modex' block; <- hangs
> ...
> 'barrier' block;
> ...
> Thanks,
> Victor Kocheganov.
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] Duplicated modex issue.
Hi.
I have an issue with understanding /ompi_mpi_init() /logic. Could you
please tell me if you have any guesses about following behavior.
I wonder if I understand ringh, there is a block in /ompi_mpi_init()
/function for exchanging procs information between processes (denote
this block 'modex'):
coll = OBJ_NEW(orte_grpcomm_collective_t);
coll->id = orte_process_info.peer_modex;
if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(coll))) {
error = "orte_grpcomm_modex failed";
goto error;
}
/* wait for modex to complete - this may be moved anywhere in
mpi_init
* so long as it occurs prior to calling a function that needs
* the modex info!
*/
while (coll->active) {
opal_progress(); /* block in progress pending events */
}
OBJ_RELEASE(coll);
and several instructions after this there is a block for processes
synchronization (denote this block 'barrier'):
coll = OBJ_NEW(orte_grpcomm_collective_t);
coll->id = orte_process_info.peer_init_barrier;
if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(coll))) {
error = "orte_grpcomm_barrier failed";
goto error;
}
/* wait for barrier to complete */
while (coll->active) {
opal_progress(); /* block in progress pending events */
}
OBJ_RELEASE(coll);
So,//initially///ompi_mpi_init()/ has following structure:
...
'modex' block;
...
'barrier' block;
...
I made several experiments with this code and the following one is of
interest: if I add sequence of two additional blocks, 'barrier' and
'modex', right after 'modex' block, then///ompi_mpi_init() /hangs in
/opal_progress()/ of the last 'modex' block.
...
'modex' block;
'barrier' block;
'modex' block; <- hangs
...
'barrier' block;
...
Thanks,
Victor Kocheganov.
Re: [OMPI devel] openmpi-1.7rc5 on cygwin ; results and patches
Many thanks, Macro! I'll examine these in January when I return from vacation. There certainly won't be an OMPI 1.6.x release before then, anyway. On Dec 20, 2012, at 8:18 AM, marco atzeri wrote: > On 12/20/2012 1:59 PM, Jeff Squyres wrote: >> Thank you! I've filed https://svn.open-mpi.org/trac/ompi/ticket/3437 about >> this. >> >> Do you have any Open MPI v1.6-specific patches that would be useful to merge >> upstream? I've looked through my email and don't see any, but I could be >> missing them. >> >> > > Hi Jeff, > these 3 are the one used on 1.6.x > >>> path_null.patch : https://svn.open-mpi.org/trac/ompi/ticket/3371 >>> SHM.patch : posix alternative at "SHM_R | SHM_W" >>> cygwin-dlname.patch : cygwin specific for .dll instead of .so suffix >>> > > path_null.patch is already in > > SHM.patchis generic enough that should work on any platform. > Please check > > cygwin-dlname.patch as written is windows only. > It needs a configuration check for choosing the > right shared library suffix for the platform > > > Marco > > ___ > 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] [Open MPI] #3351: JAVA scatter error
(taking the liberty of moving this thread to the devel list...) On Dec 19, 2012, at 9:22 AM, Siegmar Gross wrote: >> I think the real shortcoming is that there is no Datatype.Resized >> function. That can be fixed. > > Are you sure? That would at least solve one problem. I think so. We "own" the bindings now, so adding a method is hypothetically possible. I can have a look at adding that over the holidays, but I make no promises... >> I noticed that if I used [][] in my version of the Scatter program, >> I got random results. But if I used [] and did my own offset >> indexing, it worked. > > I think if you want a 2D-matrix you should use a Java matrix and not > a special one with your own offset indexing. In my opinion that is > something a C programmer can/would do (I'm a C programmer myself with > a little Java knowledge), but the benefit of Java is that the programmer > should not know about addresses, memory layouts and similar things. Understood, and I agree. But if Java doesn't give any guarantees about memory layout, then how is MPI supposed to handle this? > Now > I sound like my colleagues who always claim that my Java programs look > more like C programs than Java programs :-(. I know nothing about the > memory layout of a Java matrix or if the layout is stable during the > lifetime of the object, but I think that the Java interface should deal > with all these things if that is possible. It's quite possible/likely that Java implementations do deal with this stuff -- they *have* to, right? But they don't necessarily expose it to external libraries (like MPI), thereby making it impossible to do low-level actions, like directly accessing memory. (again, I could be wrong here -- I'm NOT a Java expert!) FWIW: Fortran 2008 had similar issues. The MPI Forum had to directly interact with the Fortran language standards body to get them to change some of these guarantees so that MPI could access some of Fortran's lower-layer information. > I suppose that Open MPI will > not succeed in the Java world if it requires "special" matrices and a > special offset indexing. Perhaps some members of this list have very > good Java knowledge or even know the exact layout of Java matrices so > that Datatype.Vector can build a Java column vector from a Java matrix > which even contains valid values. Any Java expert input would be welcomed here... >> Remember: there is no standard for MPI and Java. So there is no >> "must". :-) > > I know and I'm grateful that you try nevertheless to offer a Java > interface. Hopefully you will not misunderstand my "must". It wasn't > complaining, but trying to express that a "normal" Java user would > expect that he can implement an MPI program without special knowledge > about data layouts. Fair enough. Don't worry; I greatly appreciate the time and input that you're spending on this. :-) >> ...snip... >> Again, here's my disclaimer that I'm not a Java guy... :-) But does >> this mean you need to define an operator[] method on your class, and >> that would allow this casting to work? (not that I'm sure what this >> method would need to *do*, but this is a first step...) > > Alternatively the buffer parameter type could be changed from "Object" > to "Object[]". Then everybody would know that an array is expected > (even for a single value). However, I don't know if that has a > consequence which breaks other things. Is a different parameter type > possible or out-of any question? I got an out-of-band answer from a Java-expert friend yesterday that suggested a better way to do this -- he suggested using a ByteArrayOutputStream. I'll try to look at this over the holidays. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] openmpi-1.7rc5 on cygwin ; results and patches
On 12/20/2012 1:59 PM, Jeff Squyres wrote: Thank you! I've filed https://svn.open-mpi.org/trac/ompi/ticket/3437 about this. Do you have any Open MPI v1.6-specific patches that would be useful to merge upstream? I've looked through my email and don't see any, but I could be missing them. Hi Jeff, these 3 are the one used on 1.6.x path_null.patch : https://svn.open-mpi.org/trac/ompi/ticket/3371 SHM.patch : posix alternative at "SHM_R | SHM_W" cygwin-dlname.patch : cygwin specific for .dll instead of .so suffix path_null.patch is already in SHM.patchis generic enough that should work on any platform. Please check cygwin-dlname.patch as written is windows only. It needs a configuration check for choosing the right shared library suffix for the platform Marco
Re: [OMPI devel] openmpi-1.7rc5 on cygwin ; results and patches
Thank you! I've filed https://svn.open-mpi.org/trac/ompi/ticket/3437 about this. Do you have any Open MPI v1.6-specific patches that would be useful to merge upstream? I've looked through my email and don't see any, but I could be missing them. On Dec 19, 2012, at 12:50 PM, marco atzeri wrote: > > Built and tested openmpi-1.7rc5 on cygwin, same configuration > than 1.6.3-4 package > >./autogen.sh >configure \ >LDFLAGS="-Wl,--export-all-symbols -no-undefined" \ >--disable-mca-dso \ >--disable-sysv-shmem \ >--without-udapl \ >--enable-cxx-exceptions \ >--with-threads=posix \ >--without-cs-fs \ >--enable-heterogeneous \ >--with-mpi-param_check=always \ >--enable-contrib-no-build=vt,libompitrace \ > --enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv > > > In addition to the previous 3 patches: > path_null.patch : https://svn.open-mpi.org/trac/ompi/ticket/3371 > SHM.patch : posix alternative at "SHM_R | SHM_W" > cygwin-dlname.patch : cygwin specific for .dll instead of .so suffix > > I needed additional patches: > ERROR.patch : ERROR is already defined, so another label >is needed for "goto ERROR" > interface.patch : same for interface , it seems a >struct somewhere else > min.patch : min already defined as macro >(I saw in the source also a MIN macro defined) > mpifh.patch : to avoid undefined error >libmpi_mpifh_la_LIBADD needs >$(top_builddir)/ompi/libmpi.la > winsock.patch : defense against usage > > > Full package here : > http://matzeri.altervista.org/cygwin-1.7/openmpi/ > > Osu-micro-benchmarks-3.7 results here : > http://matzeri.altervista.org/works/ompi/ > > Regards > Marco > ___ > 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/
