Re: [Bug 375] New - Fix for autoconf >2.5

----- Original Message -----
From: "Henrik Nordstrom" <hno@marasystems.com>
To: "Robert Collins" <robert.collins@syncretize.net>;
<squid-dev@squid-cache.org>
Sent: Saturday, July 06, 2002 6:58 PM

> > I really don't think it's worth putting time into trying to have a
> > 2.5x and 2.13 configure.in when there are what - 6 people? that
> > regulary need to create configure, and as the platform where
> > configure is created doesn't matter, we can do that anywhere!
>
> I am mostly worried about users who need to patch Squid or otherwise
> play around with the code.
>
> Upgrading autoconf or automake on a system should not be taken lightly
> as it has a large impact on the ability to build other programs based
> on autoconf/automake (quite many GNU or GNU inspired programs relies
> a bit too much on being able to use these tools)

Ok. Even so, patches to configure.in should be the exception, not the rule.

As for the specifics of the LIBOBJS change, here's the autoconf manual
section:

In particular, note that we'd need to generate traces conditionally in M4 to
be compatible with both 2.13 and 2.5x.

For now, I'm going to create a branch with the fully upgraded configure.in,
and we can publish a patch on that for anyone who needs 2.5x compatible
configure.in.

Rob

===
AC_LIBOBJ vs. LIBOBJS
Up to Autoconf 2.13, the replacement of functions was triggered via the
variable LIBOBJS. Since Autoconf 2.50, the macro AC_LIBOBJ should be used
instead (see Generic Functions). Starting at Autoconf 2.53, the use of
LIBOBJS is an error.
This change is mandated by the unification of the GNU Build System
components. In particular, the various fragile techniques used to parse a
configure.ac are all replaced with the use of traces. As a consequence, any
action must be traceable, which obsoletes critical variable assignments.
Fortunately, LIBOBJS was the only problem.
At the time this documentation is written, Automake does not rely on traces
yet, but this is planed for a near future. Nevertheless, to ease the
transition, and to guarantee this future Automake release will be able to
use Autoconf 2.53, using LIBOBJS directly will make autoconf fail. But note
that the output, configure, is correct and fully functional: you have some
delay to adjust your source.
There are two typical uses of LIBOBJS: asking for a replacement function,
and adjusting LIBOBJS for Automake and/or Libtool.

As for function replacement, the fix is immediate: use AC_LIBOBJ. For
instance:

LIBOBJS="$LIBOBJS fnmatch.o"
LIBOBJS="$LIBOBJS malloc.$ac_objext"

should be replaced with:

AC_LIBOBJ([fnmatch])
AC_LIBOBJ([malloc])

When asked for automatic de-ANSI-fication, Automake needs LIBOBJS'ed
filenames to have $U appended to the base names. Libtool requires the
definition of LTLIBOBJS, which suffixes are mapped to .lo. Although Autoconf
provides them with means to free the user to do that by herself, by the time
of this writing, none do. Therefore, it is common to see configure.ac end
with:

# This is necessary so that .o files in LIBOBJS are also built via
# the ANSI2KNR-filtering rules.
LIBOBJS=`echo "$LIBOBJS" | sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'`
LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.o/\.lo/g'`
AC_SUBST(LTLIBOBJS)

First, note that this code is wrong, because .o is not the only possible
extension4! Because the token LIBOBJS is now forbidden, you will have to
replace this snippet with:

# This is necessary so that .o files in LIBOBJS are also built via
# the ANSI2KNR-filtering rules.
LIB@&t@OBJS=`echo "$LIB@&t@OBJS" |
             sed 's,\.[[^.]]* ,$U&,g;s,\.[[^.]]*$,$U&,'`
LTLIBOBJS=`echo "$LIB@&t@OBJS" |
           sed 's,\.[[^.]]* ,.lo ,g;s,\.[[^.]]*$,.lo,'`
AC_SUBST(LTLIBOBJS)

Unfortunately, autoupdate cannot help here, since... this is not a macro! Of
course, first make sure your release of Automake and/or Libtool still
requires these.
Received on Sat Jul 06 2002 - 04:41:53 MDT