Actually, I thought about this more.
There is a way to not break ABI, but still adhere to MPI-3.
Let me go work up a patch and see if it's horrible; I think it will be a matter
of reverting *some* of the code, but not *all* of it.
On Jan 28, 2014, at 5:35 PM, Jeff Squyres wrote:
> It looks
It looks like Past Jeff was wrong: the removal of the choice buffers from the
non-ignore-TKR version of the Fortran mpi module (which is only used for
gfortran <=v4.8) *does* cause ABI breakage between 1.7.3 and 1.7.4.
Per discussion on the telconf today, we decided that we're going to do this
Fixed - thanks for the heads-up.
On Jan 28, 2014, at 3:40 PM, "Dave Goodell (dgoodell)"
wrote:
> On Jan 28, 2014, at 2:18 PM, Orion Poplawski wrote:
>
>> Why does mpio.h get installed? For the Fedora package I end up with:
>>
>> /usr/lib64/openmpi/include/mpio.h
>>
>> but it is listed her
On 28/01/2014 04:54, Jeff Squyres (jsquyres) wrote:
In the usual location:
http://www.open-mpi.org/software/ompi/v1.7/
Lots of changes since 1.7.4rc1, but we didn't keep a good NEWS file between the
two, so I can't list them all here.
On cygwin 64 bit, except for the known noinline fai
On Jan 28, 2014, at 2:18 PM, Orion Poplawski wrote:
> Why does mpio.h get installed? For the Fedora package I end up with:
>
> /usr/lib64/openmpi/include/mpio.h
>
> but it is listed here in openmpi-1.7.4rc2/ompi/mca/io/romio/romio/Makefile.am:
>
> # nodist_ b/c these are created by config.sta
On 01/27/2014 08:54 PM, Jeff Squyres (jsquyres) wrote:
> In the usual location:
>
> http://www.open-mpi.org/software/ompi/v1.7/
>
> Lots of changes since 1.7.4rc1, but we didn't keep a good NEWS file between
> the two, so I can't list them all here.
>
Why does mpio.h get installed? For th
w00t!
On Jan 28, 2014, at 11:16 AM, Paul Hargrove wrote:
> My posts normally convey bad news.
> So, I figured I'd take this opportunity to provide some good news for a
> change.
>
> Nearly all my tests have completed and there are no failures (other than ones
> know to be due compiler bugs or
My posts normally convey bad news.
So, I figured I'd take this opportunity to provide some good news for a
change.
Nearly all my tests have completed and there are no failures (other than
ones know to be due compiler bugs or similar).
The only "work-arounds" (patches applied or extra configure swi
This looks okay to me. Couple of comments:
1. if you don't want to create your own callback function, you can use the
standard one. It does more than you need, but won't hurt anything:
ORTE_DECLSPEC void orte_rml_recv_callback(int status, orte_process_name_t*
sender,
