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/
