[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange LT_INIT behavior

From: Jeff Squyres
Subject: Re: Strange LT_INIT behavior
Date: Mon, 18 May 2009 20:56:04 -0400

On May 16, 2009, at 12:08 AM, Peter O'Gorman wrote:

> - 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 ...?

I haven't checked, but I'd guess that this is not limited to darwin,
it seems like a bug to me that on linux with GNU ld, libtool reports
that /usr/bin/true can create shared libraries.

This is true, even Linux GNU ld reports that /bin/true can make shared libraries:

checking for /bin/true option to produce PIC...
checking if /bin/true static flag  works... no
checking if /bin/true supports -c -o file.o... no
checking if /bin/true supports -c -o file.o... (cached) no
checking whether the /bin/true linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes

Can you move LT_INIT to come just after AC_PROG_CC, but before
AC_PROG_CXX, AC_PROG_F77 etc.? If so then doing so should, I think,
make libtool not check other languages, then checking all the other
languages conditionally would make the libtool language checks
conditional too.

Nifty idea!

Unfortunately, it runs into a bit of a snag -- AC_PROG_F77 first checks for g77; we have long-since overridden this ordering with our own:

AC_PROG_F77([gfortran g77 f77 xlf frt ifort pgf77 fort77 fl32 af77])

If I move up LT_INIT to shortly after AC_PROG_CC (but before AC_PROG_CXX|F77|F90), then C++ Libtool tests come *after* AC_PROG_CXX, but the Libtool tests for F77 seem to come *before* we call AC_PROG_F77, and therefore call AC_PROG_F77 with the default ordering; not the ordering that we want.

Hence, g77 is found instead of gfortran. This, unfortunately, is a dealbreaker for us. :-(

Is there another way?

Jeff Squyres
Cisco Systems

reply via email to

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