Re: AM_FCFLAGS not working as I expect...

[Alan W. Irwin]

We have just added a fortran 9x interface for the PLplot package (to join
our already existing fortran 77 interface), and it works well with gfortran
when configured using the latest stable autotools packages from GNU.  To be
specific, the tarballs are autoconf-2.59.tar.bz2, automake-1.9.6.tar.bz2,
and libtool-1.5.22, which are unpacked, built, and installed from scratch
(with the special install location bin directory first on the path so there
is no interference from old system versions on my Debian stable system).
However, when one of our developers tried to use the Intel ifort compiler
rather than gfortran, he reported some problems.  When I tried the latest
CVS snapshot of libtool, I could not even get it to bootstrap properly for
our particular autotools configuration setup. Details follow with a summary
of the current status at the end.

Here is the original problem report.
********
I have ifort 9.1 installed. With a clean plplot checkout and the latest
autotools (as recommended) plplot now fails to build. The fortran
compiler is detected and f95 bindings enabled. Unfortunately they don't
build. When it gets to the f95 bindings at the command

/bin/sh ../../libtool --mode=compile ifc -I../../../bindings/f95 -g -c
-o strutil.lo ../../../bindings/f95/strutil.f95

I get an error message

libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with --tag'

Same problem occurs with pgf90.
********

That last compiler is the commercial fortran compiler from the Portland Group.

After some google searching I found a thread from this mailing list that
discussed a problem very similar to above.  So I decided to resurrect the
thread again with the current post.

The last (2005-11-08) post to this thread was from Ralf (see
http://lists.gnu.org/archive/html/libtool/2005-11/msg00013.html). His post
had the following comments:

"If you use both $F77 and $FC in your package (which I believe you do),
the right thing would be to wait for Libtool-2.0 which has proper FC
support and is due pretty soon (I hope)."

"[...]Can you wait a little bit?  We're really working through the final bits
now."

The first description fits us like a glove, and as you see above we are
having similar problems to the one that started this thread.  So it looks
like libtool-2.0 should solve our current fortran problems.

I haven't been following libtool news, but hopefully you are getting close
to the release of 2.0 now from Ralf's second comment. Anyhow, I just now
tried today's CVS snapshot of libtool (the 2006-05-13 04:17 version that I
used wget http://libtool.opendarwin.org/libtool.tar.gz to obtain), but it
doesn't even bootstrap for PLplot's autotools configuration files that are
working fine with libtool-1.5.22.

Here is the message I got from our bootstrap script.

***********
address@hidden> cf/bootstrap.sh 
Running aclocal (GNU automake) 1.9.6...cf/c++.ac:71: error: m4_require: circular dependency of AC_LANG_COMPILER(C++)
cf/c++.ac:71: AC_LANG_COMPILER(C++) is required by...
autoconf/lang.m4:295: AC_LANG_COMPILER_REQUIRE is expanded from...
autoconf/general.m4:2215: AC_LINK_IFELSE is expanded from...
/home/software/autotools/install/share/aclocal/libtool.m4:903: 
_LT_SYS_MODULE_PATH_AIX is expanded from...
/home/software/autotools/install/share/aclocal/libtool.m4:6104: 
_LT_LANG_CXX_CONFIG is expanded from...
/home/software/autotools/install/share/aclocal/libtool.m4:783: _LT_LANG is 
expanded from...
/home/software/autotools/install/share/aclocal/libtool.m4:772: LT_LANG is 
expanded from...
cf/c++.ac:71: AC_PROG_CXX is required by...
autoconf/c.m4:653: AC_LANG_COMPILER(C++) is expanded from...
cf/c++.ac:71: AC_LANG_COMPILER(C++) is required by...
autoconf/lang.m4:295: AC_LANG_COMPILER_REQUIRE is expanded from...
autoconf/general.m4:2173: AC_COMPILE_IFELSE is expanded from...
cf/c++.ac:71: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
 done
Running autoheader (GNU Autoconf) 2.59... done
Running libtoolize (GNU libtool 1.2286 2006/04/22 18:57:04) 2.1a...libtoolize: 
You should add the contents of `cf/libtool.m4' to `aclocal.m4'.
libtoolize: You should add the contents of `cf/argz.m4' to `aclocal.m4'.
libtoolize: You should add the contents of `cf/ltoptions.m4' to `aclocal.m4'.
libtoolize: You should add the contents of `cf/ltsugar.m4' to `aclocal.m4'.
libtoolize: You should add the contents of `cf/ltversion.m4' to `aclocal.m4'.
libtoolize: You should add the contents of `cf/lt~obsolete.m4' to `aclocal.m4'.
 done
Running automake (GNU automake) 1.9.6... done
Running autoconf (GNU Autoconf) 2.59... done
Regenerating libltdl/aclocal+configure... done
***********

If I comment out AC_LANG_PUSH([C++]) (and the corresponding
AC_LANG_POP([C++]) from cf/c++/ac, and similarly for our fortran language
tests in cf/f77.ac and cf/f95.ac, then I can get the circular
dependency errors to go away.  The warning messages left are

***********
address@hidden> cf/bootstrap.sh 
Running aclocal (GNU automake) 1.9.6... done
Running autoheader (GNU Autoconf) 2.59... done
Running libtoolize (GNU libtool 1.2286 2006/04/22 18:57:04)
2.1a...libtoolize: You should add the contents of cf/ltdl.m4' to aclocal.m4'.
libtoolize: You should add the contents of cf/argz.m4' to aclocal.m4'.
libtoolize: You should add the contents of cf/lt~obsolete.m4' to aclocal.m4'.
 done
Running automake (GNU automake) 1.9.6... done
Running autoconf (GNU Autoconf) 2.59... done
Regenerating libltdl/aclocal+configure... done
**********

I have no idea why those three cf/*.m4 macro files are not being included
properly in aclocal.m4.  We include the line:

ACLOCAL_AMFLAGS = -I cf 2>&1 | grep -v underquoted

in our top-level Makefile.am file so that the cf/*.m4 macro files should
just automatically be included.  (At least that is what happens with
the usual libtool.)

Here is the tail end of aclocal.m4 which shows
a large number of such macros that are properly included.

tail -15 aclocal.m4 
AC_SUBST([am__untar])
]) # _AM_PROG_TAR

m4_include([cf/ac_pkg_swig.m4])
m4_include([cf/ac_python_devel.m4])
m4_include([cf/acinclude.m4])
m4_include([cf/docbook.m4])
m4_include([cf/gnome.m4])
m4_include([cf/gnu-make.m4])
m4_include([cf/gtk.m4])
m4_include([cf/libtool.m4])
m4_include([cf/ltoptions.m4])
m4_include([cf/ltsugar.m4])
m4_include([cf/ltversion.m4])
m4_include([cf/pkg.m4])

but for some reason those additional three files are missing.  Any ideas
about how to make this work properly?  I suspect this bug is independent of
the circular dependency one.

At this point, I tried configure, but because I commented out all
AC_LANG_PUSH calls to work around the above circular dependency error, all
our C++ and fortran language tests failed because gcc is used rather than
the appropriate g++ or gfortran compiler.  In other words, we really do need
AC_LANG_PUSH to work properly, and it appears not to for the CVS snapshot
version of libtool.

Here is a summary of the current status: PLplot has a fairly complicated set
of autotools configuration files, but they are reasonably well organized (we
use m4_include(cf/*.ac) a lot in configure.ac to keep our various bits of
well-commented autoconf configuration factored and ordered in a particular
way).  Thus, it is fairly easy to understand the overview of what is going
on.  I am willing to experiment and give feedback on libtool to (a) help you
out with testing on a real-world setup as you move closer to the libtool 2.0
release and (b) help us solve our original problem for users with commercial
fortran compilers.

If you have some experiments you would like me to try with the latest CVS
snapshot version of libtool please CC me since I am not currently subscribed
to this list.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________