Subject: Re: libtool generates binary data in config.log due to buggy escaping

From: Vincent Lefevre <[email-masked]>
Date: Tue, 2 Oct 2018 15:46:21 +0200

On 2018-10-02 12:58:04 +0200, Vincent Lefevre wrote:
> I've seen in the autoconf source that AC_TRY_EVAL should not be used:
> 
> # AC_TRY_EVAL(VARIABLE)
> # ---------------------
> # Evaluate $VARIABLE, which should be a valid shell command.
> # The purpose of this macro is to write "configure:123: command line"
> # into config.log for every test run.
> #
> # The AC_TRY_EVAL and AC_TRY_COMMAND macros are dangerous and
> # undocumented, and should not be used.
> # They may be removed or their API changed in a future release.
> # Autoconf itself no longer uses these two macros; they are present
> # only for backward compatibility with previous versions of Autoconf.
> # Not every shell command will work due to problems with eval
> # and quoting, and the rules for exactly what does work are tricky.
> # Worse, due to double-expansion during evaluation, arbitrary unintended
> # shell commands could be executed in some situations.

I've attached a patch that replaces the AC_TRY_EVAL occurrence that
generated the binary data. This is a patch against the Debian package
(libtool 2.4.6-4). I've tested it with MPFR and it seems to work fine.

The other AC_TRY_EVAL occurrences do not cause any problem here,
but should also be replaced in the future.

For the reference, my Debian bug report (clone of 796180, which is
now about autoconf):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910076

-- 
Vincent Lefèvre <[email-masked]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Avoid a broken AC_TRY_EVAL macro
 As said in the Autoconf source, the AC_TRY_EVAL macro is dangerous and
 undocumented, and should not be used.
 In particular, the one related to nm yields binary data in the config.log
 file with dash, where "echo \\1" (echo with the argument \1) produces the
 control character ^A instead of the usual \1 with most shells (POSIX says
 that the result is implementation-defined). See:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910076
 This patch attempts to replace this AC_TRY_EVAL occurrence by code with
 similar behavior, but using $ECHO instead of echo in order to avoid the
 backslash issue.
Author: Vincent Lefevre <[email-masked]>
Last-Updated: 2018-10-02

Index: libtool-2.4.6/m4/libtool.m4
===================================================================
--- libtool-2.4.6.orig/m4/libtool.m4
+++ libtool-2.4.6/m4/libtool.m4
@@ -4063,7 +4063,8 @@ _LT_EOF
   if AC_TRY_EVAL(ac_compile); then
     # Now try to grab the symbols.
     nlist=conftest.nm
-    if AC_TRY_EVAL(NM conftest.$ac_objext \| "$lt_cv_sys_global_symbol_pipe" \> $nlist) && test -s "$nlist"; then
+    $ECHO "$as_me:$LINENO: $NM conftest.$ac_objext | $lt_cv_sys_global_symbol_pipe > $nlist" >&AS_MESSAGE_LOG_FD
+    if eval "$NM" conftest.$ac_objext \| "$lt_cv_sys_global_symbol_pipe" \> $nlist 2>&AS_MESSAGE_LOG_FD && test -s "$nlist"; then
       # Try sorting and uniquifying the output.
       if sort "$nlist" | uniq > "$nlist"T; then
 	mv -f "$nlist"T "$nlist"