[Top][All Lists]

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

Re: AM_FCFLAGS not working as I expect...

From: Alan W. Irwin
Subject: Re: AM_FCFLAGS not working as I expect...
Date: Mon, 15 May 2006 15:23:00 -0700 (PDT)

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


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

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

and this:
| drivers/ compiling `get-drv-info.c' with per-target flags 
requires `AM_PROG_CC_C_O' in `'

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
+++  2006-05-15 13:14:27.000000000 -0700
@@ -61,27 +61,27 @@
    building the convenience version shipped with the sources],

-if test "$enable_dyndrivers" = "yes"; then
+AS_IF([test "$enable_dyndrivers" = "yes"],
+[ + LT_CONFIG_LTDL_DIR([libltdl])
   AC_CHECK_LIB(ltdl, lt_dlinit, [libltdl_in_system=yes],
-  if test "$with_ltdlsystem" = no -o "$libltdl_in_system" = no ; then
-    with_ltdlsystem=no
-    AC_CONFIG_SUBDIRS(libltdl)
-  else
-  fi
+  AS_IF([test "$with_ltdlsystem" = no -o "$libltdl_in_system" = no],
+  [  with_ltdlsystem=no
+  ],
+  [
+  ])

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

+LT_INIT([win32-dll dlopen])

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

I changed over to AS_IF (which made no difference).  Then I dropped all
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 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


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

Another minor documentation issue is that although libtoolize --help briefly
documents the new (with CVS libtool) --install option, the CVS version of 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/ 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 W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (; PLplot scientific plotting software
package (; the Yorick front-end to PLplot (; the
Loads of Linux Links project (; and the Linux Brochure Project

Linux-powered Science

reply via email to

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