[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Strange LT_INIT behavior
From: |
Jeff Squyres |
Subject: |
Strange LT_INIT behavior |
Date: |
Fri, 15 May 2009 20:56:49 -0400 |
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
- Strange LT_INIT behavior,
Jeff Squyres <=