On May 31, 2012, at 7:29 AM, Jeff Squyres wrote:
>>> We should have AC macros for all of these already.
>>
>> OK, I'll try find them to support (1) usecase described below.
>
> No, I'll find them -- sorry, I meant to look them up before I sent the last
> mail. Let me look them up and get back to you. Our configury is quite
> complicated, and I know the right places to look. :-)
Ok, this might get a little complicated. You'll probably need to use a pair of
them (this is trunk only; it's different in v1.6 because we wholly revamped the
trunk's Fortran support recently):
1. You can see all the OMPI_HAVE_FORTRAN_<type>'s at the top of mpi.h.in.
These indicate whether the Fortran compiler supports these types or not.
2. We currently define *one* Fortran type in mpi.h.in: ompi_fortran_integer_t.
It looks like we need to add the rest of them: ompi_fortran_<type>_t (these are
all in opal/include/opal_config.h, but mpi.h is a standalone, user-includeable
file, which is why it replicates a subset of all the configure-generated
results). Here's a first stab at what I think will be needed in mpi.h.in:
-----
/* A bogus type that allows us to have sentinel type values that are still
valid */
#define ompi_fortran_bogus_type_t int
/* C type corresponding to Fortran CHARACTER */
#undef ompi_fortran_character_t
/* C type corresponding to Fortran COMPLEX*16 */
#undef ompi_fortran_complex16_t
/* C type corresponding to Fortran COMPLEX*32 */
#undef ompi_fortran_complex32_t
/* C type corresponding to Fortran COMPLEX*4 */
#undef ompi_fortran_complex4_t
/* C type corresponding to Fortran COMPLEX*8 */
#undef ompi_fortran_complex8_t
/* C type corresponding to Fortran COMPLEX */
#undef ompi_fortran_complex_t
/* C type corresponding to Fortran DOUBLE COMPLEX */
#undef ompi_fortran_double_complex_t
/* C type corresponding to Fortran DOUBLE PRECISION */
#undef ompi_fortran_double_precision_t
/* C type corresponding to Fortran INTEGER*16 */
#undef ompi_fortran_integer16_t
/* C type corresponding to Fortran INTEGER*1 */
#undef ompi_fortran_integer1_t
/* C type corresponding to Fortran INTEGER*2 */
#undef ompi_fortran_integer2_t
/* C type corresponding to Fortran INTEGER*4 */
#undef ompi_fortran_integer4_t
/* C type corresponding to Fortran INTEGER*8 */
#undef ompi_fortran_integer8_t long
/* C type corresponding to Fortran INTEGER */
#undef ompi_fortran_integer_t
/* JMS -- ^^ might as well put the existing ompi_fortran_integer_t in the
middle of the list here, with all the rest */
/* C type corresponding to Fortran LOGICAL*1 */
#undef ompi_fortran_logical1_t
/* C type corresponding to Fortran LOGICAL*2 */
#undef ompi_fortran_logical2_t
/* C type corresponding to Fortran LOGICAL*4 */
#undef ompi_fortran_logical4_t
/* C type corresponding to Fortran LOGICAL*8 */
#undef ompi_fortran_logical8_t long
/* C type corresponding to Fortran LOGICAL */
#undef ompi_fortran_logical_t
/* C type corresponding to Fortran REAL*16 */
#undef ompi_fortran_real16_t long
/* C type corresponding to Fortran REAL*2 */
#undef ompi_fortran_real2_t
/* C type corresponding to Fortran REAL*4 */
#undef ompi_fortran_real4_t
/* C type corresponding to Fortran REAL*8 */
#undef ompi_fortran_real8_t
/* C type corresponding to Fortran REAL */
#undef ompi_fortran_real_t
-----
Does clang link together with gfortran? I.e., does the following work:
./configure CC=clang CXX=clang++ FC=gfortran ...
--
Jeff Squyres
[email protected]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
