FWIW: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/20 is a
placemarker for discussion for the upcoming MPI Forum meeting (next
Also, be aware that OMPI's 1.2.7 solution isn't perfect, either. You
can see from ticket 20 that it actually causes a problem if you try to
use SEEK_SET in a switch/case statement. But we did this a little
better in the trunk/v1.3 (see https://svn.open-mpi.org/trac/ompi/changeset/19494)
; this solution *does* allow for SEEK_SET to be used in a case
statement, but it does always bring in <stdio.h> (probably not a huge
The real solution is that we're likely going to change these names to
something else in the MPI spec itself. And/or drop the C++ bindings
altogether (see http://lists.mpi-forum.org/mpi-22/2008/10/0177.php).
Additionally -- I should have pointed this out in my first mail -- you
can also just use MPI_SEEK_SET (and friends). The spec defines that
these constants must have the same values as their MPI::SEEK_*
On Oct 16, 2008, at 7:57 AM, Jed Brown wrote:
> On Thu 2008-10-16 07:43, Jeff Squyres wrote:
>> On Oct 16, 2008, at 6:29 AM, Jed Brown wrote:
>> Open MPI doesn't require undef'ing of anything. It should also not
>> require any special ordering of include files. Specifically, the
>> following codes both compile fine for me with 1.2.8 and the OMPI SVN
>> trunk (which is what I assume you mean by "-dev"?):
> That's what I meant. This, works with 1.2.7 but not with -dev:
> #include <iostream>
> #undef SEEK_SET
> #undef SEEK_CUR
> #undef SEEK_END
> #include <mpi.h>
> If iostream is replaced by stdio, then both fail.
>> This is actually a problem in the MPI-2 spec; the names
>> (and friends) were unfortunately chosen poorly. Hopefully that'll be
>> fixed relatively soon, in MPI-2.2.
> It wasn't addressed in the MPI-2.1 spec I was reading, hence my
> confusion. When namespaces and macros don't play well.
>> MPICH chose to handle this situation a different way than we did, and
>> apparently requires that you either #undef something or you #define
>> MPICH-specific macro. I guess the portable way might be to just
>> define that MPICH-specific macro. It should be harmless for OMPI.
> I'll go with this, thanks.
>> FWIW, I was chatting with the MPICH developers at the recent MPI
>> meeting and showed them how we did our SEEK_* solution in Open MPI.
> Certainly the OMPI solution is better for users.
> users mailing list