[Bug]: autom4te from package autoconf doesn't recognise installed m4, thus fails to work at all

[TheOneric]

Problem description

autoreconf stopped working at all with autom4te claiming to not find a sufficiently recent GNU m4, yet such a version is installed.

What steps will reproduce the bug?

In an up-to-date Termux environment:

pkg upgrade
pkg install git autoconf automake make libtool pkg-config clang fribidi freetype harfbuzz fontconfig libpng libicu
git clone https://github.com/libass/libass.git
cd libass
autoreconf -ivf .

Currently the last step leads to:

autom4te: error: need GNU m4 1.4 or later: /data/data/com.termux/files/usr/bin/m4
[…]
autoreconf: error: aclocal failed with exit status: 1

Yet, m4 get's automatically installed and m4 --version claims it is m4 (GNU M4) 1.4.19.

This even happen's with libass commits I previously compiled from git succesfully like this in Termux. Unfortunately I can't tell anymore which exact upgrade caused the regression, since to troubleshoot I once wiped and reinstalled termux from FDroid to rule out any bugged states/package installs.

What is the expected behavior?

autoreconf is succesful, allowing to configure and compile the sources from git.

System information

Version of the presumably most relevant packages as reported by apt-cache policy:

autoconf: 2.71
automake: 1.16.4
m4: 1.4.19
libtool: 2.4.6-8
pkg-config: 0.29.2

termux-info:

Application version:
0.117
Packages CPU architecture:
arm
Subscribed repositories:
# sources.list
deb https://packages.termux.org/apt/termux-main/ stable main
# game-repo (sources.list.d/game.list)
deb https://packages.termux.org/apt/termux-games games stable
# science-repo (sources.list.d/science.list)
deb https://packages.termux.org/apt/termux-science science stable
Updatable paclages:
All packages up to date
Android version
10

[Grimler91]

Currently the last step leads to:

autom4te: error: need GNU m4 1.4 or later: /data/data/com.termux/files/usr/bin/m4
[…]
autoreconf: error: aclocal failed with exit status: 1

Yet, m4 get's automatically installed and m4 --version claims it is m4 (GNU M4) 1.4.19.

Please share the full output so we can see what it runs.

Does not happen on aarch64 so probably arm specific. Possibly related to #7232

[TheOneric]

Does not happen on aarch64

Interesting. (Btw is it possible to log into the Termux environment via adb or such? Retyping the full logs is a bit clunky)

aoutreconf: export WARNINGS=
autoreconf: entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autom4te: error: need GNU m4 1.4 or later: /data/data/com.termux/files/usr/bin/m4
aclocal: error: /data/data/com.termux/files/usr/bin/autom4te failed with exit status: 1
autoreconf: error: aclocal failed with exit status: 1

The physical CPU is armv7 btw (should be application type armv7-A, uname says armv7l, not sure what the l-suffix stands for here)

[Grimler91]

Btw is it possible to log into the Termux environment via adb or such

Yeah, see for example: https://glow.li/posts/access-termux-via-usb/

should be application type armv7-A, uname says armv7l, not sure what the l-suffix stands for here

I think the l just indicates that it is "little-endian", but what exactly the model numbers mean are beyond me.

I will dig out an arm device to see if I can reproduce it later. Do you get any more information if you run aclocal --force --verbose -I m4?

[Grimler91]

Running autom4te is enough to trigger the issue. This check fails:

m4 --help </dev/null 2>&1 | grep reload-state >/dev/null

For som reason m4 --help </dev/null gives an error m4: write error: Bad address on arm, but not other arches

[TheOneric]

Thanks for locatinf the issue and pushing a workaround so quickly! Also thanks for the adb link!
Can confirm it now works as expected, though I'm at a loss regarding why m4 --help </dev/null fails in the first place.

I'm not sure if you want to keep this issue open as a reminder about the underlying issue with m4 --help </dev/null, so I'll refrain from closing it myself, but feel free to do so.

[xtkoba]

PR #7701 is yet another workaround that makes m4 --help </dev/null work properly.

For a "proper" fix, we would need to modify the function close_stdin which is registered by atexit(3), which I doubt is worth while doing.

[Grimler91]

@xtkoba great, thanks! Do you have any reference for why this is needed, for only arm? Is it a problem with the ndk or a problem in the source code of m4?

[xtkoba]

I am sorry but I have not yet investigated this problem further. I just came up with the workaround by looking at the strace output:

write(1, "Report bugs to: bug-m4@gnu.org\n", 31Report bugs to: bug-m4@gnu.org
) = 31
write(1, "GNU M4 home page: <https://www.g"..., 53GNU M4 home page: <https://www.gnu.org/software/m4/>
) = 53
write(1, "General help using GNU software:"..., 64General help using GNU software: <https://www.gnu.org/gethelp/>
) = 64
futex(0xb6e9f61c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
mprotect(0xb6eac000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0xb6eac000, 4096, PROT_READ)   = 0
_llseek(0, 0, [0], SEEK_CUR)            = 0
lseek(0, 0, SEEK_CUR)                   = 0
_llseek(0, 0, [0], SEEK_SET)            = 0
close(0)                                = 0
write(1, "General help using GNU software:"..., 1194966816) = -1 EFAULT (Bad address)
close(1)                                = 0
write(2, "./m4:", 5./m4:)                    = 5
write(2, " ", 1 )                        = 1
write(2, "write error", 11write error)             = 11
write(2, ": Bad address", 13: Bad address)           = 13
write(2, "\n", 1
)                       = 1
exit_group(1)                           = ?
+++ exited with 1 +++