Branden sent me a link from Planet Debian where one of the Debian developers talks about improving the packaging for Open MPI in Debian. Nice to see people outside the core development community get excited about Open MPI.

Now if only we could get people to spell it Open MPI instead of OpenMPI 😉

A not-unfrequent problem we have with Open MPI is users specifying incompatible compiler flags for the different languages used in Open MPI. This frequently occurs when a user wants to build 64-bit on a system that defaults to 32-bit and provides the right CFLAGS, but skips one of the FFLAGS, FCFLAGS, CXXFLAGS, or OBJCFLAGS. If you’re lucky, you’ll get an amorphous error during configure time saying something completely unrelated to the original problem went wrong. If you’re unlucky, nothing bad will happen until you try to link ompi_info, which is one of the last things that gets built.

I wrote a macro for Open MPI today that tries to link a small C function in a .o file with a main function in either Fortran (either 90 or 77) or one of the C-like languages (C++ / Objective C) to see if they link. The result is not pretty, and I’m hoping there’s a better way to do this, but this is what I came up with (below). The only part I’m really not happy with is all the code to deal with the Fortran calling. I’m sure there’s a better way than defining a particular m4 variable then looking at that for the rest of the function. But such is life…

dnl -*- shell-script -*-
dnl
dnl Copyright (c) 2006      Los Alamos National Security, LLC.  All rights
dnl                         reserved. 
dnl $COPYRIGHT$
dnl 
dnl Additional copyrights may follow
dnl 
dnl $HEADER$
dnl

# OMPI_LANG_LINK_WITH_C(language)
# -------------------------------
# Try to link a small test program against a C object file to make
# sure the compiler for the given language is compatible with the C
# compiler.
AC_DEFUN([OMPI_LANG_LINK_WITH_C], [
  AS_VAR_PUSHDEF([lang_var], [ompi_cv_c_link_$1])

  AC_CACHE_CHECK([if C and $1 are link compatible],
    lang_var,
    [m4_if([$1], [Fortran], 
       [m4_define([ompi_lang_link_with_c_fortran], 1)],
       [m4_if([$1], [Fortran 77],
          [m4_define([ompi_lang_link_with_c_fortran], 1)],
          [m4_define([ompi_lang_link_with_c_fortran], 0)])])
     m4_if(ompi_lang_link_with_c_fortran, 1,
       [OMPI_F77_MAKE_C_FUNCTION([testfunc_name], [testfunc])],
       [testfunc_name="testfunc"])

     # Write out C part
     AC_LANG_PUSH(C)
     rm -f conftest_c.$ac_ext
      cat > conftest_c.$ac_ext << EOF
int $testfunc_name(int a);
int $testfunc_name(int a) { return a; }
EOF

     # Now compile both parts
     OMPI_LOG_COMMAND([$CC -c $CFLAGS $CPPFLAGS conftest_c.$ac_ext],
       [AC_LANG_PUSH($1)
        ompi_lang_link_with_c_libs="$LIBS"
        LIBS="conftest_c.o $LIBS"
        ompi_lang_link_with_c_fortran
        m4_if(ompi_lang_link_with_c_fortran, 1, 
          [AC_LINK_IFELSE([AC_LANG_PROGRAM([], [
       external testfunc
       call testfunc(1)
])],
             [AS_VAR_SET(lang_var, ["yes"])], [AS_VAR_SET(lang_var, ["no"])])],
          [AC_LINK_IFELSE([AC_LANG_PROGRAM([
#if defined(c_plusplus) || defined(__cplusplus)
extern "C" int testfunc(int);
#else
extern int testfunc(int);
#endif
], 
             [return testfunc(0);])],
             [AS_VAR_SET(lang_var, ["yes"])], [AS_VAR_SET(lang_var, ["no"])])])
        LIBS="$ompi_lang_link_with_c_libs"
        AC_LANG_POP($1)],
       [AS_VAR_SET(lang_var, ["no"])])
     rm -f conftest_c.$ac_ext
     AC_LANG_POP(C)])

  AS_IF([test "AS_VAR_GET([lang_var])" = "yes"], [$2], [$3])
  AS_VAR_POPDEF([lang_var])dnl
])

I ran into a problem with Open MPI’s build system today and have come up with a reasonable, but sub-optimal solution. The basics of the problem are that we need to support both the combinations of Autoconf 2.59/Automake 1.9.6 and Autoconf 2.60+/Automake 1.10+ in a project using Objective C (only for a very small, optional component). AC 2.59/AM 1.9.6 have basically zero support for Objective C, but AC 2.60+/AM 1.10 have full support for Objective C. I had back-ported in a bunch of macros to get the bare minimum support we needed for Objective C with AC 2.59, but that all conflicted with AC 2.60, so needed to be optionally provided. So there were two problems:

• How to determine whether to provide compatibility AC_PROG_OBJC or use AC’s macro
• How to prevent using AC 2.60 with AM 1.9.6

The problem with the first one is that looking at AC_PROG_OBJC seemed to cause all kinds of entertaining things to happen with AC 2.60. So the solution there was to peek at the internal structures for AC and get the version number, then act accordingly. After figuring out all the macros I needed to provide, this worked reasonably well. Look at config/ompi_objc.m4 to see which ones we ended up needing.

Automake doesn’t seem to provide an internal macro with its version number, so I couldn’t do the obvious to find the version number and do all the logic to make sure we never see AC 2.60 used with AM 1.9.6 (which would give us half support for Objective C and be a major pain). So the best I could come up with was to use the version requirement checking feature of AM_INIT_AUTOMAKE:

m4_if(m4_version_compare(m4_defn([m4_PACKAGE_VERSION]), [2.60]), -1,
  [AM_INIT_AUTOMAKE([foreign dist-bzip2 subdir-objects no-define])],
  [AM_INIT_AUTOMAKE([foreign dist-bzip2 subdir-objects no-define 1.10])])

It’s really vile, but it does work…