Fix NetBSD on AMD64 and i386 when g95 is in path

[ompiteam]

Per thread here:

http://www.open-mpi.org/community/lists/devel/2014/01/13748.php

Paul Hargrove discovered an issue on NetBSD-6 on AMD64 when g95 is in the path. We updated README to say "this doesn't work" in r 30269.

Paul volunteered (in http://www.open-mpi.org/community/lists/devel/2014/01/13761.php) to fix this for real (somehow) for 1.7.5 or later.

[ompiteam]

Imported from trac issue 4104. Created by jsquyres on 2014-01-13T15:19:38, last modified: 2014-01-17T18:01:15

[ompiteam]

Trac comment by phargrov on 2014-01-14 03:08:12:

The problem is that libtool thinks g95 (or f95) generates a.out format, though it actually generates ELF on NetBSD-6.x for AMD64 and i386 (among others). This leads to big problems building and linking the fortran support.

The breakage is from libtool.m4:

netbsd*)
  version_type=sunos
  need_lib_prefix=no
  need_version=no
  if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
    finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
    dynamic_linker='NetBSD (a.out) ld.so'
  else
    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
    soname_spec='${libname}${release}${shared_ext}$major'
    dynamic_linker='NetBSD ld.elf_so'
  fi
  shlibpath_var=LD_LIBRARY_PATH
  shlibpath_overrides_runpath=yes
  hardcode_into_libs=yes
  ;;

Which is going to try to run $FC as $CC, including expecting -E to work.
Well, -E works, but g95 doesn't predefine the macros that gcc does:

$ echo __ELF__ | /usr/pkg/bin/g95 -E -            
Warning (116): Reading file <stdin> as free form
__ELF__

But gfortran (which is newer anyway) does:

$ echo __ELF__ | /usr/pkg/gcc47/bin/gfortran -E  -
# 1 "<stdin>"
# 1 "<command-line>"
# 1 "<stdin>"
1

So, until/unless an improved/correct probe for a.out-vs-ELF is introduced the recommended work around is to install a recent gcc package, which will include gfortran, and ensure it is in your path when configuring OpenMPI.

The bug remains open in the hope I find an actual solution.

[ompiteam]

Trac comment by phargrov on 2014-01-14 03:14:02:

For the record, the same flawed logic is used by libtool on OpenBSD too.

[ompiteam]

Trac comment by jsquyres on 2014-01-14 06:31:04:

FWIW, it sounds like whatever solution is discovered should be sent upstream to Libtool, too (this is probably obvious, but I'm stating it for completeness).

[ompiteam]

Trac comment by phargrov on 2014-01-17 16:51:14:

The "broken" logic in libtool is

   if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null

and it is broken because $CC is set to f95 or g95, which are '''not''' C compilers.
While they do implement a -E option to preprocess, they don't pre-define __ELF__ (nor any other things one expects from a C compiler).

The logic appears to be a well-intended adaptation of the following from the [http://www.netbsd.org/docs/elf.html#elf-how-to-tell NetBSD ELF FAQ]:

---

== How do I tell if my system is ELF? ==
If you are running an ELF system your compiler will define the constant __ELF__. You can use this in your C programs of course but you can also use the following shell script to determine it as well.

if echo __ELF__ | ${CC:-cc} -E - | grep -q __ELF__
then echo "Not ELF"
else echo "It is an ELF system"
fi

---

The error, in my opinion, was replacing ${CC:-cc} with just $CC.

Since this is an ABI/object-format probe it should be assumed (at least in the context of Open MPI) that $CC and $FC are link compatible. So, for Open MPI I am considering a work-around that skips the broken test if it has run before (for the C and C++ compilers). Unfortunately that is not a fix that can be pushed upstream to libtool because it depends on the fact that OMPI's configure probes the C compiler before the Fortran compiler.

[ompiteam]

Trac comment by phargrov on 2014-01-17 18:01:15:

Replying to [comment:4 phargrov]:
[...]

So, for Open MPI I am considering a work-around that skips the broken test if it has run before (for the C and C++ compilers). Unfortunately that is not a fix that can be pushed upstream to libtool because it depends on the fact that OMPI's configure probes the C compiler before the Fortran compiler.

No luck to be found down that road because it appears the libtool M4 macros are (near enough to) stateless. Adding state goes a bit beyond what one can (safely) achieve using perl s// commands in autogen.pl.