[mpich2-dev] Missing symbols when configuring with --disable-f77 --disable-f90

[Lisandro Dalcin]

On Mon, Aug 3, 2009 at 3:44 PM, Dave Goodell<goodell at mcs.anl.gov> wrote:
> On Aug 3, 2009, at 1:23 PM, Lisandro Dalcin wrote:
>
> ...
>>
>> then the following symbols are not available in the MPI library:
>>
>> - MPI_Type_create_f90_integer
>> - MPI_Type_create_f90_real
>> - MPI_Type_create_f90_complex
>
> ...
>>
>> - MPI_Status_c2f
>> - MPI_Status_f2c
>>
>> Any chance that if Fortran bindings are disabled (or in case a Fortran
>> compiler is not available), the MPI library still provide these
>> symbols? The code in "src/binding/f90" seems to cope (or could more or
>> less easily cope) with the case of missing Fortran configuration info.
>> Additionally, MPI_Status has a so simple layout that some assumptions
>> could take place and still provide MPI_Status_{c2f|f2c}.
>
> AFAIK isn't a good way to provide these functions when f77/f90 are disabled.
>  Furthermore I don't think that we can write safe "dummy" implementations
> since we aren't actually checking the Fortran build environment.
>

What about providing the symbols, but make the call generate an error?
Other MPI implementations do this, for example OpenMPI without ROMIO;
also Microsoft MPI precisely for MPI_Type_create_f90_XXX ...


> IMO the right fixes in this case are on either the user's side (don't
> disable f77/f90)

Many people out there are using a pre-built MPICH2. They do not have
control about how MPICH2 is built, so they cannot make the choice of
enabling/disabling Fortran. They just have to live with what the
sysadmin or the Linux distro provides...

So we cannot rely on users, next it seems that mpi4py's author is in
charge of alleviating users for these issues :-) . Despite you put the
work on my shoulders, I'm fine with that but ...

> or on mpi4py's side (add configure checks and possibly a
> dummy library of your own).
> You could alter the bindings for those 5 or so
> missing functions to throw an exception if the user calls those functions in
> python and they are not available in the underlying MPI library.
>

mpi4py already provide the mechanism to do so. The problem is that
checking for every possible missing bit of any MPI implementation is
really time consumming. So I've decided to not enable it by default.
Perhaps I should change my mind and check for every of the 555 MPI
symbols (that's my count for what I'm using in mpi4py)...

Dave, I could live with a MPICH2 that does not provide the missing
calls. In fact, I live just fine with MPICH2 do not providing the I/O
calls if ROMIO not was configured... I can live with that because I
can make (BTW, non-standard) compile time choices "#if defined(MPICH2)
&& !defined(ROMIO_VERSION)".

What I cannot buy easily is MPICH2 providing a "mpi.h" header saying
that "MPI_<Something>" is there, but the library does not have
"MPI_<Something>"... If MPICH2 would provide at least a way to use the
C preprocessor to handle at compile time the missing stuff...

Please, Dave, try to take my place for a bit of time... Suppose you
are trying to build a wrapper for a language other than
C/C++/Fortran... It is really really hard to do a good job. You have
to write workarounds for whatever interpretation of corner cases in
the standard the MPI implementation takes. You have to support plus
MPI-1 only, MPI-1 and bits of MPI-2, and full MPI-2 calls. Next you
have to cope with dynamic linking issues (and the do-nothing policy of
Open MPI folks). Now add to the equation that every MPI implementation
out there will decide what to provide and what not to provide in the
MPI header/library, or use funny calling conventions (MS MPI on Win32,
with BTW does not even follow 100% their own conventions)... and then
you get really lost and angry because you want to do it well, but it
is SO hard...


In short, Dave, is there any chance that if MPICH2 cannot provide a
implementation for these calls, then do one of:

Option 1) Make the symbol available, but make it fail (I mean, MPI
error) at runtime.

Option 2) Provide a macro in "mpi.h" (or an additional header that can
be conditionally #include'd?) advertising the missing call, and
perhaps even to not list the call in the "mpi.h" header?



-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594