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
