Re: AM_FCFLAGS not working as I expect...

[Alan W. Irwin]

On 2006-05-15 06:11+0200 Ralf Wildenhues wrote:
> [...]So, the patch below moves those compiler tests up, and invokes the
> libtool macro afterwards.  This eliminates that circular dependency.
> Since in PL_GET_DLNAME (used from within cf/tcl.ac) you use the built
> libtool script to gather further information, those tests have to come
> after AC_PROG_LIBTOOL.  There is another important change: by default,
> the `libtool' script will only be created at the end of the configure
> run.  Use LT_OUTPUT to enable earlier build of the script.
>
> * Alan W. Irwin wrote on Sun, May 14, 2006 at 09:47:16PM CEST:
> > [...]When I added the --install option to those other options, that only
> > partially solved the problem.  ltdl.m4 is now properly included in
> > aclocal.m4, but the two others (argz.m4 and lt~obsolete.m4) still generate
> > the error message and are not included in aclocal.m4.
>
> First, it's a warning and not an error (libtoolize exits successfully),
> and second, the warning about argz.m4 and lt~obsolete.m4 is bogus.  We
> aim to fix it before 2.0 comes out.  For now you can just ignore it.

OK.

> [...]Other than that, CVS Automake warns about some GNU make-specific stuff
> in doc/docbook/src/Makefile.am (which I guess you know about)

Yes.  The only way we can build our documents is on Linux distros with GNU
make.

> and this:
> | drivers/Makefile.am:77: compiling `get-drv-info.c' with per-target flags 
> requires `AM_PROG_CC_C_O' in `configure.ac'
>
> so if you want to be portable to compilers that don't understand "-c
> -o", you could add AM_PROG_CC_C_O right after AC_PROG_CC (the `compile'
> script will then be used).
>
> And then, due to macro requirements from macros inside shell
> conditionals, some spurious extra `yes' and a couple of errors turned
> up.  Using AS_IF from Autoconf-2.59c fixes that (AS_IF works with 2.59
> also but won't cause the required macros to be expanded outside the
> conditional, unlike the 2.59c AS_IF).  And AC_PROG_CXX should be used
> before tests for the C++ compiler are used.
>
> The following is where I stopped at, due to insufficient development
> packages installed on my system.  Let's see how this works for you.
[patch followed]

I applied your patch which bootstrapped quite nicely, but did not configure
properly.  The problem was that lt_ltdl_dir was set to the empty string
in the configure script so the libltdl directory could not be found.

Here is the patch I applied (on top of your patch) to fix that:

**************
--- libtool.ac_ralf     2006-05-15 11:52:01.000000000 -0700
+++ libtool.ac  2006-05-15 13:14:27.000000000 -0700
@@ -61,27 +61,27 @@
    building the convenience version shipped with the sources],
   no)

-if test "$enable_dyndrivers" = "yes"; then
-  AC_LIBTOOL_DLOPEN
+AS_IF([test "$enable_dyndrivers" = "yes"],
+[ 
+  LT_CONFIG_LTDL_DIR([libltdl])
   AC_CHECK_LIB(ltdl, lt_dlinit, [libltdl_in_system=yes],
     [libltdl_in_system=no])
-  if test "$with_ltdlsystem" = no -o "$libltdl_in_system" = no ; then
-    with_ltdlsystem=no
-    AC_LIBLTDL_CONVENIENCE
-    AC_CONFIG_SUBDIRS(libltdl)
-  else
-    AC_LIBLTDL_INSTALLABLE
-  fi
-fi
+  AS_IF([test "$with_ltdlsystem" = no -o "$libltdl_in_system" = no],
+  [  with_ltdlsystem=no
+    LTDL_CONVENIENCE
+  ],
+  [
+    LTDL_INSTALLABLE
+  ])
+])
 AC_SUBST(INCLTDL)
 AC_SUBST(LIBLTDL)

 dnl This required for dll support under cygwin.  Must occur before
 dnl AC_PROG_LIBTOOL

-LT_INIT([win32-dll])
+LT_INIT([win32-dll dlopen])
+LT_WITH_LTDL
 LT_OUTPUT

 AM_CONDITIONAL(with_ltdlsystem, [test "$with_ltdlsystem" = yes])
-
-
**************

I changed over to AS_IF (which made no difference).  Then I dropped all
the legacy calls to AC_LIBTOOL_DLOPEN, AC_LIBLTDL_CONVENIENCE,
AC_LIBLTDL_INSTALLABLE, and AC_CONFIG_SUBDIRS, and instead used
the recommended LTDL_CONVENIENCE (the one I use by default) or
LTDL_INSTALLABLE, added dlopen to the LT_INIT options lists, and finished
by invoking LT_WITH_LTDL just as in the CVS libtool.info example.
I don't know which of the legacy macros were setting lt_ltdl_dir to
the empty string, but with the above patch to use the recommended
macros the resulting configure script sets

lt_ltdl_dir='libltdl'

which gives the correct ./configure result.  I don't mind a bit if the
legacy macros don't work.  However, currently most (all?) of the legacy
macros are not mentioned at all in the CVS version of libtool.info. My own
feeling is that is a mistake, and a better way to notify others about the
problem is you should actively warn against using the legacy macros in
libtool.info.

Another minor documentation issue is that although libtoolize --help briefly
documents the new (with CVS libtool) --install option, the CVS version of
libtool.info does not.

Once the configure script worked properly, I followed with make, make
install, and a build and execution of our 96 test plot examples which gave
identical results to our standard PLplot tree (without your patch or mine)
and libtool-1.5.22.

This is not a complete test since my test system did not have development
versions of free java, octave, and tcl (some of our additional interfaces to
PLplot) installed.  Also, the tests were for just our postscript device
driver, and not for our other ~20 device drivers.  Also, I have no access to
commercial fortran compilers such as ifort and pgf90 so I could not test
whether cvs libtool could handle those cases. Nevertheless, these excellent
initial tests results are an encouraging sign both for CVS libtool and
PLplot, and I will continue to test your recommended changes on other
systems (and also for libtool-1.5.22 without the --install option on
libtoolize and without any of the changes in cf/libtool.ac since all those
are specific to CVS libtool).

Ralf, thanks very much for your extensive help in getting the PLplot project
ready for libtool-2.x.  Let me know if there is anything more I can do
for the libtool team in the way of testing CVS libtool.

Best wishes,

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
__________________________