Problem with --version after compiling autoconf

[Andy Armstrong]

I want to update from autoconf 2.62 to 2.69.

I downloaded the source and ran the following:

./configure
make
make install


These all complete successfully.

When I run autoconf --version I get the following:

autoconf --version
autoconf (GNU Autoconf) ?K??
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.


The problem you see here is that the version reports as ?K??.

Why could this be? My machine runs in the EBCDIC codepage and I am wondering if this could be associated. Is there a configure / make option I need to add.

This issues stops me compiling other software, as the configure scripts check the version autoconf reports and it ends up failing those checks.

Please help!

[Eric Blake]

On 05/29/2018 08:05 PM, Andy Armstrong wrote:
> The problem you see here is that the version reports as ?K??.
>
> Why could this be? My machine runs in the EBCDIC codepage and I am wondering if this could be associated.

Very likely that this is related, if not the cause. However, I don't
have access to an EBCDIC machine to debug things, so you'll probably
have to do the debugging yourself.

> Is there a configure / make option I need to add.

No, but then again, no one else has ever written this list stating that
they are using autoconf on an EBCDIC machine. So there may be lots of
things that need tweaking to work correctly.

I suppose you could start by running 'make check', and then pasting the
testsuite.log of the failing tests, if that might contain hints of where
things are going wrong.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc. [phone]
Virtualization: qemu.org | libvirt.org

[Andy Armstrong]

Hi Eric,


I ran 'make check' and got the following :


>make check
make check-recursive
Making check in bin
Making check in .
Making check in lib
Making check in Autom4te
Making check in m4sugar
make check-local
Making check in autoconf
make check-local
Making check in autotest
make check-local
Making check in autoscan
Making check in emacs
Making check in doc
make: Makefile: line 436: Warning -- FSUM9433 Duplicate entry [fdl.texi] in prerequisite list
Making check in tests
make check-local
cd ../lib/autotest && make autotest.m4f
`autotest.m4f' is up to date
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/lib --language=autotest -I . -I . suite.at -o ./testsuite.tmp
m4:local.at:18: bad expression in eval (bad input): ((?+1+0) > (2+0)) - ((?+1+0) < (2+0))
autom4te: /workarea/tools/m4/bin/m4 failed with exit status: 1
FSUM8226 make: Error code 1
FSUM8226 make: Error code 255
FSUM8226 make: Error code 1
FSUM8226 make: Error code 255



No testsuite.log file was created.


I appreciate your help and support. Thoughts from here?


Andy


________________________________
From: Eric Blake <***@redhat.com>
Sent: 30 May 2018 02:13
To: Andy Armstrong; ***@gnu.org
Subject: Re: Problem with --version after compiling autoconf

On 05/29/2018 08:05 PM, Andy Armstrong wrote:
> The problem you see here is that the version reports as ?K??.
>
> Why could this be? My machine runs in the EBCDIC codepage and I am wondering if this could be associated.

Very likely that this is related, if not the cause. However, I don't
have access to an EBCDIC machine to debug things, so you'll probably
have to do the debugging yourself.

> Is there a configure / make option I need to add.

No, but then again, no one else has ever written this list stating that
they are using autoconf on an EBCDIC machine. So there may be lots of
things that need tweaking to work correctly.

I suppose you could start by running 'make check', and then pasting the
testsuite.log of the failing tests, if that might contain hints of where
things are going wrong.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc. [phone]
Virtualization: qemu.org | libvirt.org

[Eric Blake]

On 05/30/2018 03:24 AM, Andy Armstrong wrote:
> Hi Eric,
>
>
> I ran 'make check' and got the following :
>

> autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/lib --language=autotest -I . -I . suite.at -o ./testsuite.tmp

The command looks reasonable,

> m4:local.at:18: bad expression in eval (bad input): ((?+1+0) > (2+0)) - ((?+1+0) < (2+0))
> autom4te: /workarea/tools/m4/bin/m4 failed with exit status: 1

but things are choking hard at:

m4_version_prereq([2.57])

which expands:

[m4_if(m4_version_compare(]m4_dquote(m4_defn([m4_PACKAGE_VERSION]))[, [$1]),
[-1],
[m4_default([$3],
[m4_fatal([Autoconf version $1 or higher is required],
[63])])],
[$2])]


which in turn is expanding this macro before calling m4's eval with
invalid input:

m4_bpatsubst(m4_bpatsubst(m4_translit([[[[0,$1]]]], [.-], [,,]),]dnl
m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+],
[+1,-1,[0r36:\&]]), [,0], [,[0r10:0]])

What are the contents of lib/m4sugar/version.m4? But I suspect that
part is fine.

Actually, I'm now quite certain that the m4_bpatsubst is not properly
transliterating EBCDIC values into a base-36 number. And in fact,
looking at m4's source code, the problem is in m4 itself:

m4/src/eval.c:eval_lex()


/* FIXME - this calculation can overflow. Consider xstrtol. */
*val = 0;
for (; *eval_text; eval_text++)
{
if (isdigit (to_uchar (*eval_text)))
digit = *eval_text - '0';
else if (islower (to_uchar (*eval_text)))
digit = *eval_text - 'a' + 10;
else if (isupper (to_uchar (*eval_text)))
digit = *eval_text - 'A' + 10;

which means that anything larger than radix 20 (0-9 and a-j) is botched
on an EBCDIC machine.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc. [phone]
Virtualization: qemu.org | libvirt.org

[Eric Blake]

On 05/30/2018 07:23 AM, Eric Blake wrote:

> which in turn is expanding this macro before calling m4's eval with
> invalid input:
>
> m4_bpatsubst(m4_bpatsubst(m4_translit([[[[0,$1]]]], [.-], [,,]),]dnl
> m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+],
>               [+1,-1,[0r36:\&]]), [,0], [,[0r10:0]])

In fact, this used to work for single (but not multiple) letters; commit
6e1d6e2c (added in 2.63, Oct 2007) changed from a manual comparison of
the three contiguous regions of a-z in EBCDIC into using m4's 0r36:NNN
notation:

-[m4_translit(m4_bpatsubsts(m4_tolower([[$1]]),
- [\([0-9]+\)\([abcdefghi]\)],
- [m4_eval(\1 + 1).-1.\2],
- [\([0-9]+\)\([jklmnopqrs]\)],
- [m4_eval(\1 + 1).-1.1\2],
- [\([0-9]+\)\([tuvwxyz]\)],
- [m4_eval(\1 + 1).-1.2\2]),
- [abcdefghijklmnopqrstuvwxyz],
- [12345678901234567890123456])])
+[m4_map_sep([m4_eval], [.], _$0([$1]))])
+m4_define([_m4_version_unletter],
+[m4_translit(m4_bpatsubst([[[$1]]], ]dnl
+m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+],
+ [+1.-1.[0r36:\&]]),

So you've found a 10-year-old bug in autoconf, and an even older bug in
m4. As least as far back as m4 commit bd11691d (Feb 2000, marked
"Initial revision", which is when the current m4.git history starts),
and the m4 1.4 release, m4's eval(0r36:NN) notation has been broken;
more likely, all the way back to Nov 1993 when Francois Pinard
introduced 0rNNN syntax into m4 1.1 (according to NEWS), although I
cannot locate a tarball or version control of m4 that old.

It's worth patching m4 to not botch large-radix numbers on EBCDIC, but
it's also possible to patch autoconf to quit relying on large-radix
numbers; I'll probably end up patching both projects, when I get a chance.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc. [phone]
Virtualization: qemu.org | libvirt.org

[Paul Eggert]

On 05/30/2018 05:49 AM, Eric Blake wrote:
> more likely, all the way back to Nov 1993 when Francois Pinard
> introduced 0rNNN syntax into m4 1.1 (according to NEWS), although I
> cannot locate a tarball or version control of m4 that old.

Some old GNU tarballs can be find at funet (Linux's first distributor). And:

http://www.nic.funet.fi/index/gnu/funet/historical-funet-gnu-area-from-early-1990s/m4-1.1.tar.gz

says that the bug in question is indeed in m4 1.1 dated 1993-11-08.

As far as I know, this holds the record for the oldest bug reported in
GNU software so far this year. (Maybe we should give Andy a prize; how
about a plaque inscribed in EBCDIC? :-)