[Top][All Lists]

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

Re: use of AC_TRY_EVAL broken

From: Eric Blake
Subject: Re: use of AC_TRY_EVAL broken
Date: Thu, 23 Oct 2008 20:15:34 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080914 Thunderbird/ Mnenhy/

Hash: SHA1

According to Bruno Haible on 10/23/2008 5:09 PM:
> There is a need for autoconf macros to compile and execute programs that
> they have created with AC_LANG_CONFTEST
>   1) without having to build up the compile or link command by itself,
>   2) with log of the command and its error messages and exit code to the log
>      file.

Yes, but it probably should not be named AC_TRY_EVAL, so that existing
uses of the undocumented and broken interface aren't themselves broken
when we close the security hole in whatever we document.  In particular,
AC_TRY_EVAL is an undocumented interface which, in the autoconf sources
itself, mentions that it is unsafe and may be withdrawn or changed in the

>   ac_gcj_link="$GCJ $GCJFLAGS --main=conftest -o 
> conftest$ac_exeext"
>   AC_TRY_EVAL([ac_gcj_link])

It sounds like we need to add a public wrapper around _AC_DO_VAR and
_AC_DO_TOKENS, as those are the safe replacements for the broken AC_TRY_EVAL.

> In libtool you find many uses of
>   AC_TRY_EVAL(ac_compile)
> and
>   AC_TRY_EVAL(ac_link)
> but also two more complicated ones:
>   AC_TRY_EVAL(NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \> 
> $nlist)
>   AC_TRY_EVAL(_LT_TAGVAR(archive_cmds, $1) 2\>\&1 \| $GREP \" -lc \" 
> \>/dev/null 2\>\&1)

Right now, I think a close start for the alternative would be some wrapper
_AC_DO_TOKENS([$NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \>

_AC_DO_TOKENS(_LT_TAGVAR(archive_cmds, $1) [2\>\&1 \| $GREP \" -lc \"
\>/dev/null 2\>\&1])

> So, not only AC_TRY_EVAL should be documented, but also the variables 
> 'ac_link'
> and 'ac_compile'.

Better than documenting variables would be designing a nicer macro
interface that exposes what those variables are trying to get at.  Every
time we document a shell variable instead of an autoconf macro, we've
locked ourself into a particular implementation, instead of hiding behind
a stable API where we can tune for performance.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

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