I like your suggestion better -- if we can somehow report during the
compile/link that the reason for the error is because Open MPI was not compiled
with Fortran support, that would definitely be preferable.
FWIW: my suggestion was because I wanted to convey the *reason* for the error
(i.e., that OMPI has no Fortran support), and a pragma-based solution didn't
occur to me. I didn't want to follow Gilles' suggestion of just removing the
symbols, because that will lead to other confusion (e.g., "Hey, Open MPI is not
compliant because it doesn't have Fortran datatypes available in C!").
Gilles: do you want to poke around and see if you can make any of Jeff's
suggestions work out nicely? (i.e., give some kind of compile/link error that
states that Open MPI was not built with Fortran support?)
On Feb 8, 2016, at 8:55 AM, Jeff Hammond <jeff.scie...@gmail.com> wrote:
>
> Waiting until runtime to issue this error is a terrible idea, because then
> the PETSc team (among others) will disparage you for allowing a user to
> successfully build against an unusable library. They are on-record numerous
> times in the past as to the evils of e.g. no-op symbols in MPI or other
> runtime libraries, since this means that compile- and link-based tests pass,
> even though nothing good will happen when the user employs them in an
> application.
>
> The right thing to do is what Gilles proposed: do not define the types in
> mpi.h so that it is impossible to compile C code with Fortran datatypes, if
> Fortran datatypes are not supported. There are more and less effective ways
> to do this, in terms of letting the user know what is happening. For
> example, you can just not define them, which might confuse novices who don't
> know how to read error messages (HPC users are frequent offenders).
>
> You could use e.g.:
>
> #define MPI_DOUBLE_PRECISION choke me No Fortran support when library was
> compiled!
>
> Unfortunately, Clang colorized output emphasizes the wrong problem here, and
> ICC doesn't even echo the message at all in its error message. GCC issues
> the same error four times, and makes it relatively hard to miss the message.
>
> If the following GCC extension is supported, along with C99/C++11, you could
> do this:
>
> #define MPI_DOUBLE_PRECISION _Pragma("GCC error \"MPI was not compiled with
> Fortran support\"")
>
> For the _functions_ that require Fortran support, you can use e.g.
> __attribute__((error("no Fortran"))) on the function declaration, although
> neither ICC nor Clang support this, and it ends up throwing two error
> messages when compiled (only one - the right one - when only preprocessed),
> which might confuse the same folks that it is trying to help.
>
> Best,
>
> Jeff
>
> On Mon, Feb 8, 2016 at 5:14 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com>
> wrote:
> The issue at hand is trying to help the user figure out that they have an
> open MPI built without fortran support.
>
> Perhaps we should improve the error reporting at run time to display
> something about the fact that you used a fortran data type but have an OMPI
> that was compiled without fortran support.
>
> Sent from my phone. No type good.
>
> On Feb 8, 2016, at 4:00 AM, Gilles Gouaillardet
> <gilles.gouaillar...@gmail.com> wrote:
>
>> That being said, should we remove these fortran types from include files and
>> libs when ompi is configure'd without fortran support ?
>>
>> Cheers,
>>
>> Gilles
>>
>> Jeff Hammond <jeff.scie...@gmail.com> wrote:
>>
>> > BTW: is there a reason you don't want to just use the C datatypes? The
>> > fundamental output of the index is an integer value -- casting it to a
>> > float of some flavor doesn't fundamentally change its value.
>>
>> The code in question is not mine. I have suggested to the developers that
>> they should use the correct C types. The reason I became aware of this
>> issue is that one of my colleagues compiled and ran this code on a system
>> where OpenMPI was built without Fortran support and the code started failing
>> with errors from MPI which were not seen on other systems.
>>
>>
>> If you use an MPI library compiled without Fortran support, you should
>> expect precisely nothing related to Fortran to work. You might get more
>> than this because the universe is being nice to you, but you should treat it
>> as serendipity when something works, not a bug when something doesn't.
>>
>> Jeff
>>
>>
>> --
>> Jeff Hammond
>> jeff.scie...@gmail.com
>> http://jeffhammond.github.io/
>> _______________________________________________
>> users mailing list
>> us...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> Link to this post:
>> http://www.open-mpi.org/community/lists/users/2016/02/28459.php
>
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2016/02/28460.php
>
>
>
> --
> Jeff Hammond
> jeff.scie...@gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2016/02/28461.php
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
