bug-gnulib
[Top][All Lists]
Advanced

[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:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
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
future.

> 
>   ac_gcj_link="$GCJ $GCJFLAGS conftest.java --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
around:
_AC_DO_TOKENS([$NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \>
$nlist])

_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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkBL8YACgkQ84KuGfSFAYCi1wCgwka0Zrx9t2UinrAc9QJZ+93r
u84AoI1fn7Qlv3gYVoCutIAtvgev/6x6
=qukv
-----END PGP SIGNATURE-----




reply via email to

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