autoconf-patches
[Top][All Lists]
Advanced

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

Re: Debian-specific Autoconf patches


From: Ralf Wildenhues
Subject: Re: Debian-specific Autoconf patches
Date: Tue, 30 May 2006 09:58:49 +0200
User-agent: Mutt/1.5.11

* Paul Eggert wrote on Tue, May 30, 2006 at 09:41:08AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> > this is horrendously ugly, but look:
> >
> >   if AC_TRY_EVAL(NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \> 
> > $nlist) && test -s "$nlist"; then
> 
> Just this line alone doesn't explain why the change would break this
> usage.

Hmm.  Oh.

> Unless perhaps $lt_cv_sys_global_symbol_pipe expands into some
> horrible string value with unescaped '"'?  (That certainly would
> explain your "horrendous". :-)

Yes.  $lt_cv_sys_global_symbol_pipe expands into something horrible
and complicated.

> > What am I going to replace the above with, so it works with both
> > Autoconf versions, pre- and post this change?
> 
> I don't have an answer for you, partly because I don't understand the
> example.  However, I'll take your word for it that the change breaks
> something somehow.

Thanks.  I will try to take some time to look into this post-2.60, and
clean up this part of Libtool.

> > let's revert this part of the patch, and post-2.60, let's
> > create _differently named_ macros which are actually safe,
> 
> I'm not sure we can come up with safe ones, not without a major
> rewrite (e.g., use shell functions). 

Yes; I don't see why shell functions should not help us there.

> However, it shouldn't hurt to
> bring back AC_TRY_COMMAND and AC_TRY_EVAL with their old meanings.
> Presumably that would fix the above example.

Thanks.  Yes, apparently it does.

> > (Autoconf hasn't worried about potential hazards for years,
> 
> I'm not particularly worried about these hazards being run into by
> accident.  I'm worried about their deliberate misuse.  (I'd rather not
> think too hard about how to misuse them.  :-)

I don't see the attack scenario here: the person running configure has
to trust the developer anyway.

> Anyway, I installed this to bring back the old AC_TRY_COMMAND and
> AC_TRY_EVAL.  If this doesn't address the problem please let me know.

Looks ok; except that I can even find usage of _AC_EVAL out in the wild:
http://www.berenddeboer.net/eiffel/eiffel.m4  sigh.

Cheers,
Ralf

> 2006-05-30  Paul Eggert  <address@hidden>
> 
>       * lib/autoconf/general.m4: Revert AC_TRY_EVAL and AC_TRY_COMMAND,
>       since evidently some packages rely on the old, broken behavior.
>       Problem reported by Ralf Wildenhues in
>       
> <http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00160.html>.
>       (AC_TRY_EVAL, AC_TRY_COMMAND, _AC_EVAL): Go back to the
>       pre-2006-05-26 definitions, but leave in the comments that
>       these macros are dangerous and should not be used.
>       (_AC_DO_ECHO): Renamed from _AC_EVAL_ECHO.  All callers changed.
>       (_AC_DO): Renamed from _AC_EVAL.  All callers changed.
>       (_AC_DO_STDERR): Renamed from _AC_EVAL_STDERR.  All callers changed.
>       (_AC_DO_VAR): Renamed from AC_TRY_EVAL.
>       (_AC_DO_TOKENS): Renamed from AC_TRY_COMMAND.




reply via email to

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