Package: libtool Version: 2.4.6-15 Severity: grave Tags: patch Justification: renders package unusable X-Debbugs-Cc: erjoa...@gmail.com
Dear Maintainer, While building isc-dhcpd-server, I tried using autoreconf as per instructions to generate the ./configure file. But running `autoreconf -i` on this project failed with this error: /usr/bin/libtoolize: 1: eval: hookable_fns+=: not found /usr/bin/libtoolize: 1: eval: hookable_fns+=: not found /usr/bin/libtoolize: 1: eval: hookable_fns+=: not found /usr/bin/libtoolize: 1: eval: hookable_fns+=: not found libtoolize: error: 'func_options_prep' does not accept hook functions. autoreconf: libtoolize failed with exit status: 1 Some others have reported this error, but the solution mentioned in that thread was to run as root, which I shouldn't have to do to build in a local directory: https://github.com/libsndfile/libsndfile/issues/132#issue-153391414 Looking at the source, I noticed the problem is not that `func_options_prep does not accept hook functions`, but that the script assumes the append operator `+=` works when it doesn't. This assumption is based on the value of BASH_VERSION, but unfortunately this is not reliable: if test set = "${BASH_VERSION+set}${ZSH_VERSION+set}"; then : ${_G_HAVE_ARITH_OP="yes"} : ${_G_HAVE_XSI_OPS="yes"} # The += operator was introduced in bash 3.1 case $BASH_VERSION in [12].* | 3.0 | 3.0*) ;; *) : ${_G_HAVE_PLUSEQ_OP="yes"} # not really! ;; esac fi It's not reliable because on my system, plain debian 11, /bin/sh is linked to /usr/bin/dash, but the BASH_VERSION environment variable appears to have been inherited from the bash process on my terminal and it is not modified or deleted by dash. And += doesn't work in dash: █[debian-x1-7th][isc-dhcp-4.4.1][0]$ ls -l /usr/bin/sh lrwxrwxrwx 1 root root 4 Apr 27 17:06 /usr/bin/sh -> dash █[debian-x1-7th][isc-dhcp-4.4.1][130]$ dash \[\]█\[\][\h][\W][0]$ \[\]echo $BASH_VERSION 5.1.4(1)-release \[\]█\[\][\h][\W][0]$ \[\]a=1 \[\]█\[\][\h][\W][0]$ \[\]a+=2 dash: 3: a+=2: not found \[\]█\[\][\h][\W][127]$ \[\] There's some advice online about how to find the true name of the shell: https://stackoverflow.com/questions/23011370/ but I think it is too complicated and error prone, and I think the simplest way to correct this is to actually test for the feature directly as is already being done in the script: (eval 'x=a; x+=" b"; test "a b" = "$x"') && _G_HAVE_PLUSEQ_OP=yes There is a comment expressing concern about speed of the test above and about minimizing forks: # We should try to minimise forks, especially on Windows where they are # unreasonably slow, so skip the feature probes when bash or zsh are # being used: But I don't see any reason for needing a fork here: if test -z "$_G_HAVE_PLUSEQ_OP" && \ __PLUSEQ_TEST="a" && \ __PLUSEQ_TEST+=" b" 2>/dev/null && \ test "a b" = "$__PLUSEQ_TEST"; then _G_HAVE_PLUSEQ_OP=yes fi Even if a fork were needed, I don't think the possible speedup of avoiding the a one-line feature probe is worth the risk of breaking users who invoke this script from a parent bash terminal. I'm including my suggested patch inline below: 527,547c527,535 < # We should try to minimise forks, especially on Windows where they are < # unreasonably slow, so skip the feature probes when bash or zsh are < # being used: < if test set = "${BASH_VERSION+set}${ZSH_VERSION+set}"; then < : ${_G_HAVE_ARITH_OP="yes"} < : ${_G_HAVE_XSI_OPS="yes"} < # The += operator was introduced in bash 3.1 < case $BASH_VERSION in < [12].* | 3.0 | 3.0*) ;; < *) < : ${_G_HAVE_PLUSEQ_OP="yes"} < ;; < esac < fi < < # _G_HAVE_PLUSEQ_OP < # Can be empty, in which case the shell is probed, "yes" if += is < # useable or anything else if it does not work. < test -z "$_G_HAVE_PLUSEQ_OP" \ < && (eval 'x=a; x+=" b"; test "a b" = "$x"') 2>/dev/null \ < && _G_HAVE_PLUSEQ_OP=yes --- > # _G_HAVE_PLUSEQ_OP > # Can be empty, in which case the shell is probed, "yes" if += is > # usable or anything else if it does not work. > if test -z "$_G_HAVE_PLUSEQ_OP" && \ > __PLUSEQ_TEST="a" && \ > __PLUSEQ_TEST+=" b" 2>/dev/null && \ > test "$__PLUSEQ_TEST" = "a b"; then > _G_HAVE_PLUSEQ_OP=yes > fi Thanks, Ernesto *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-22-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libtool depends on: ii autotools-dev 20180224.1+nmu1 ii cpp 4:10.2.1-1 ii file 1:5.39-3 ii gcc [c-compiler] 4:10.2.1-1 ii gcc-10 [c-compiler] 10.2.1-6 ii libc6-dev [libc-dev] 2.31-13+deb11u6 Versions of packages libtool recommends: ii libltdl-dev 2.4.6-15 Versions of packages libtool suggests: ii autoconf 2.69-14 ii automake [automaken] 1:1.16.3-2 pn gcj-jdk <none> ii gfortran 4:10.2.1-1 ii gfortran-10 [fortran95-compiler] 10.2.1-6 pn libtool-doc <none> -- no debconf information
527,547c527,535 < # We should try to minimise forks, especially on Windows where they are < # unreasonably slow, so skip the feature probes when bash or zsh are < # being used: < if test set = "${BASH_VERSION+set}${ZSH_VERSION+set}"; then < : ${_G_HAVE_ARITH_OP="yes"} < : ${_G_HAVE_XSI_OPS="yes"} < # The += operator was introduced in bash 3.1 < case $BASH_VERSION in < [12].* | 3.0 | 3.0*) ;; < *) < : ${_G_HAVE_PLUSEQ_OP="yes"} < ;; < esac < fi < < # _G_HAVE_PLUSEQ_OP < # Can be empty, in which case the shell is probed, "yes" if += is < # useable or anything else if it does not work. < test -z "$_G_HAVE_PLUSEQ_OP" \ < && (eval 'x=a; x+=" b"; test "a b" = "$x"') 2>/dev/null \ < && _G_HAVE_PLUSEQ_OP=yes --- > # _G_HAVE_PLUSEQ_OP > # Can be empty, in which case the shell is probed, "yes" if += is > # useable or anything else if it does not work. > if test -z "$_G_HAVE_PLUSEQ_OP" && \ > __PLUSEQ_TEST="a" && \ > __PLUSEQ_TEST+=" b" 2>/dev/null && \ > test "a b" = "$__PLUSEQ_TEST"; then > _G_HAVE_PLUSEQ_OP=yes > fi