bug#21309: libtool generates binary data in config.log due to buggy escaping
Vincent Lefevre <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.bugs |
|---|---|
| Message-ID | <[email protected]> |
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 protected]> - 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) _______________________________________________ Bug-libtool mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-libtool
libtool-eval-nm.patch
(text/plain, 1.5 KB)
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 protected]> 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"