autoconf
[Top][All Lists]
Advanced

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



reply via email to

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