[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LIBOBJS and ANSI2KNR fix?
From: |
Akim Demaille |
Subject: |
Re: LIBOBJS and ANSI2KNR fix? |
Date: |
25 Mar 2002 09:45:34 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
>>>>> "Harlan" == Harlan Stenn <address@hidden> writes:
Harlan> Thanks for your response.
>> > From: Harlan Stenn <address@hidden> > Date: Sun, 24 Mar
>> 2002 16:54:14 -0500
>> >
>> > - Do I still need to worry about this problem with LIBOBJS and
>> ANSI2KNR?
>>
>> I think the answer is "no".
Harlan> I did a quick test tonight, and it's fixed in 2.52. I'm not
Harlan> sure about 2.50.
Err, I don't know what you name `fixed'. You still have to do that.
There is a section in the documentation about this issue. There is
all the needed material so that you no longer need it (namely,
Automake and Libtool ought to use AC_CONFIG_COMMANDS_PRE to set their
variables), but none has it done yet.
`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 (*note 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 extension(1)! 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@&address@hidden "$LIB@&address@hidden" |
sed 's,\.[[^.]]* ,$U&,g;s,\.[[^.]]*$,$U&,'`
LTLIBOBJS=`echo "$LIB@&address@hidden" |
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.
---------- Footnotes ----------
(1) Yet another reason why assigning `LIBOBJS' directly is
discouraged.