[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:


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_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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]