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/