Cached exeext values with Libtool 1.4 and autoconf 2.50

[Matthias Koeppe]

When trying to build CVS Guile with Libtool 1.4, autoconf 2.50 and CVS
automake on Solaris, I noticed that libtool and autoconf seem to
disagree about the meaning of the ac_exeext variable.  This results in
the string "no" being attached to the names of all built executables.

This only happens if a cache is in use during the configure process;
it only goes away if I invoke configure with --cache-file=/dev/null.
(Note that starting with an empty or non-existing cache file does not
help; so this is really a problem with the cache system; the problem
is not caused by stale cache values from old versions.)

I tried to find through a maze of files all the same; here are my
results:

 * Older autoconfs seem to set ac_exeext=no to indicate that no exe
   extension is in use; autoconf 2.50 seems to make ac_exeext empty. 

 * From autoconf ChangeLog:

    | 2001-01-22  Lars J. Aas  <address@hidden>
    | 
    |         * aclang.m4 (_AC_COMPILER_EXEEXT_DEFAULT, _AC_COMPILER_EXEEXT_O):
    |         Export ac_cv_exeext so ltconfig believes the value is cached and
    |         skips its own faulty test.

 * From libtool ChangeLog:

    | 1999-06-09  Gary V. Vaughan  <address@hidden>
    | 
    |         * ltconfig.in (exeext): autoconf's AC_EXEEXT uses "no" to indicate
    |         no extension, and we must do the same in order to share the cache
    |         value. Also we must ignore conftest.err which HPsUX (at least)
    |         fills with gratuitous warnings.

 * An ac_exeext value of "no" seems to creep into the cache file
   during the configuration of the convenience ltdl copy in Guile.  I
   built libtool with autoconf 2.50 and libtoolized Guile with this
   build, so I think the ltdl copy is up-to-date w.r.t. the autoconf
   version. 

Does this make sense to anyone?

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe