Strange LT_INIT behavior

[Jeff Squyres]

Here's another report from the wild Open MPI project...

A user has discovered some strange behavior on OS X Leopard (10.5.x);  
I am able to replicate it on my MacBook Pro, but I am unable to  
replicate the same behavior on Linux.  This might be a resurgence of  
an old, long-standing issue: the F77 and FC checks occur in LT_INIT,  
even if they're not needed or desired.  Or we could be doing something  
wrong in configure.ac.  :-)

The user (Bryan, CC'ed) has a strangely-functioning Fortran compiler  
named g95 in his path -- Libtool essentially determines that this  
compiler does not support shared libraries.  You can simulate this  
behavior with (on OS X):

   ./configure FC=/bin/true F77=/bin/true ...

which effectively results in Libtool finding non-functional "fortran  
compilers".

Open MPI defaults to enable shared, disable static via calls to the  
following up relatively near the beginning of configure.ac:

AM_ENABLE_SHARED
AM_DISABLE_STATIC

We use the value of $enable_shared and $enable_static a few places  
throughout configure.ac (mainly in passing arguments down to sub- 
configure calls, because AC_CONFIG_SUBDIRS does not seem to work for  
all non-GNU compilers).  Down near the bottom of configure.ac, we  
finally call LT_INIT.  Right before the call to LT_INIT,  
$enable_static=no / $enable_shared=yes.  After the call to LT_INIT,  
the values have switched: $enable_static=yes, $enable_shared=no.  I  
tested this with:

echo =================== enable_shared/static before LT INIT:  
$enable_shared / $enable_static
LT_INIT([dlopen win32-dll])
echo =================== enable_shared/static after LT INIT:  
$enable_shared / $enable_static

This change in values becomes problematic because we have already used  
the previous values -- and we then later get mismatches in the build  
process.

Remember: this only happens on OS X/Leopard -- it does not seem to  
happen on Linux.

I found a workaround: setting FC and F77 to "no" tricks LT_INIT into  
thinking that no Fortran compilers were found, and therefore the  
Fortran checks in LT_INIT are skipped.  $enable_static /  
$enable_shared therefore don't change, and all is Right with the world.

I attached 4 files:

- configure stdout/stderr, and corresponding config.log, when passing  
FC=/bin/true and F77=/bin/true
  --> Search for "===" -- you can see the $enable_shared|static  
values changing before and after LT_INIT

- configure stdout/stderr, and corresponding config.log, when passing  
FC=no and F77=no
  --> Search for "===" -- you can see the $enable_shared|static  
values staying the same before and after LT_INIT, and that the Fortran  
checks are skipped in LT_INIT

Note that Open MPI conditionally builds Fortran 77 or Fortran 90  
support; so our configure.ac does contain calls to AC_PROG_F77 and  
AC_PROG_F90 -- although AC_PROG_F90 is not always called.  It looks  
something like this (pseudocode; the real code is a bit more complex):

  if test "$enable_mpi_f90" = "yes"; then
      AC_PROG_F90
  fi

AC_PROG_F77 is always invoked, even if --disable-mpi-f77 is specified  
on the configure command line (for various, uninteresting esoteric  
reasons that I hope are not relevant here!).

Does anyone have a suggestion to work around this LT_INIT-changes- 
enable_static|shared-values behavior?  Here's some possibilities that  
occur to me:

- Before LT_INIT is invoked, should Open MPI's configure.ac set F77=no  
if --disable-mpi-f77 is specified, and FC=no if --disable-mpi-f90 is  
specified?
- Or is there another way to tell Libtool "I don't want support for  
F77 / F90"?
- Or is it a bug that LT_INIT is resetting $enable_shared /  
$enable_static?
- Or ...?

Thanks for your time.

--
Jeff Squyres
Cisco Systems

lt-init-oddity.tar.bz2
Description: BZip2 compressed data