Bug 617766

Adding -save-temps to gcc invocation I see that that lines becomes:

__attribute__((__visibility__("default"))) ompi_predefined_datatype_t ompi_mpi_logical1 = { { { (&(ompi_datatype_t_class)), 1 }, (0x0040 | 0x0004 | 0x0080 | 
 0x0100 | 0x0002) | 0xC000 | (0), (0x17), 1, 0 , 1 , 0 , 1 , (), 1, (((uint64_t)1)<<(0x17)), ((void *)0), 0, "MPI_" "LOGICAL1", {0, 0, ((void *)0)}, {0, 0, 
((void *)0)}, ((void *)0), ((void *)0), { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0 } } };

Looks to me like "1 , (), 1 " is the problem

Looking near top of file:
#define INIT_BASIC_FORTRAN_TYPE( TYPE, NAME, SIZE, ALIGN, FLAGS )             \
    { BASEOBJ_DATA, DT_FLAG_BASIC | DT_FLAG_DATA_FORTRAN | (FLAGS),           \
            (TYPE), SIZE, 0/*true_lb*/, SIZE/*true_ub*/, 0/*lb*/, SIZE/*ub*/, \
            (ALIGN), 1, (((uint64_t)1)<<(TYPE)), EMPTY_DATA(NAME) }
suggests that the "()" is the ALIGN from that macro

"config.h" has this empty macro definition, leading to the compilation failure:
/* Alignment of Fortran 77 LOGICAL*1 */
#define OMPI_ALIGNMENT_FORTRAN_LOGICAL1

"configure" generates it thus:
cat >>confdefs.h <<_ACEOF                                                                                                                                    
#define OMPI_ALIGNMENT_FORTRAN_LOGICAL1 $ofc_type_alignment                                                                                                  
_ACEOF                                                                                                                                                       

(wordwrapped by bugzilla)

Relevant fragment from configure.ac appears to me:
OMPI_F77_CHECK([LOGICAL*1], [yes],
               [char, int8_t, short, int32_t, int, int64_t, long long, long], [1])

(In reply to comment #3)
> "config.h" has this empty macro definition, leading to the compilation failure:
> /* Alignment of Fortran 77 LOGICAL*1 */
> #define OMPI_ALIGNMENT_FORTRAN_LOGICAL1
> 
> "configure" generates it thus:
> cat >>confdefs.h <<_ACEOF                                                       
> #define OMPI_ALIGNMENT_FORTRAN_LOGICAL1 $ofc_type_alignment                     
> _ACEOF                                                                          
> 

about 30 lines before this, $ofc_type_alignment is set as
   ofc_type_alignment=`eval 'as_val=${'type_var'};$as_echo "$as_val"'`

whereas in the F-13 build at the same place, we have
   ofc_type_alignment=$ompi_cv_f77_alignment_LOGICALp1

autotools is playing games with us.

Very very ugly hack. But doing a

sed -i 's|ofc_type_alignment=`eval.*|ofc_type_alignment=$ompi_cv_f77_alignment_LOGICALp1|' configure

right before the %configure makes the build finish:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=2347485

Can we use this hack until the real solution is found so that we can finish the python builds?

(Note to openmpi devs: this is blocking "boost" in the python 2.7 rebuild, and thus quite a few other packages).

Thanks for workaround.

As you say, it's an ugly hack.  I was a bit worried that it might duplicate the value of LOGICAL*1 for all values, so I tried an alternate approach: I noticed that the captured value appears in $ac_res in each test, so I tried this workaround:
sed -i \
  's|ofc_type_alignment=`eval.*`|ofc_type_alignment=$ac_res|g' \
  configure

This worked in a scratch build:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=2348248
so I committed it to CVS and am trying this build (1.4.1-6):
  http://koji.fedoraproject.org/koji/taskinfo?taskID=2348272

Having said that, I checked the logs of your scratch build, and it does look like it got the various alignments correct.

Some more notes:

The generated header file is: opal/include/opal_config.h

The code that generates the relevant part of the configure script seems to be:

config/f77_check.m4 contains:
AC_DEFUN([OMPI_F77_CHECK], [

    (snip)
  ofc_type_alignment=$ac_cv_sizeof_int

    (snip)

            # Get the alignment of the type
            if test "$ofc_have_type" = "1"; then
                OMPI_F77_GET_ALIGNMENT([$1], [ofc_type_alignment])
            fi

    (snip)

  [OMPI_ALIGNMENT_FORTRAN_]m4_bpatsubst(m4_bpatsubst([$1], [*], []), [[^a-zA-Z0-9_]], [_])[=$ofc_type_alignment]

    (snip)
])dnl

config/f77_get_alignment.m4 has the definition:
# OMPI_F77_GET_ALIGNMENT(type, shell variable to set)
# ----------------------------------------------------
AC_DEFUN([OMPI_F77_GET_ALIGNMENT],[

            OMPI_F77_GET_ALIGNMENT([$1], [ofc_type_alignment])
which appears to be where the code in comment #5 is generated from


The body of that macro appears to set "type_var" from conftestval:
           [AS_VAR_SET(type_var, [`cat conftestval`])],
(with various error handling conditions)

Rebuild was successful, which (when it hits the buildroot) will unblock parts of the stack.

However, given that this is a workaround, I'm going to leave this bug open: please can the openmpi maintainers review this and figure out the root cause and a more robust fix.

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This doesn't appear to be a problem with recent openmpi versions as the workaround is no longer present and yet builds work.  This is likely due to the fact that we no longer run the autogen.sh script, and so we don't regenerate the configure scripts, and the shipped script works.  Closing this out.