GNU bug report logs - #20831
Can m4 be built without automake?

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: automake; Reported by: Eric Blake <eblake@HIDDEN>; dated Tue, 16 Jun 2015 21:41:03 UTC; Maintainer for automake is bug-automake@HIDDEN.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 16 Jun 2015 21:40:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 16 17:40:17 2015
Received: from localhost ([127.0.0.1]:56357 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Z4yad-00071j-3C
	for submit <at> debbugs.gnu.org; Tue, 16 Jun 2015 17:40:16 -0400
Received: from eggs.gnu.org ([208.118.235.92]:41596)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eblake@HIDDEN>) id 1Z4yaZ-00071V-Sp
 for submit <at> debbugs.gnu.org; Tue, 16 Jun 2015 17:40:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1Z4yaT-0008EP-13
 for submit <at> debbugs.gnu.org; Tue, 16 Jun 2015 17:40:06 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:39880)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1Z4yaS-0008Dv-VB
 for submit <at> debbugs.gnu.org; Tue, 16 Jun 2015 17:40:04 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55087)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1Z4yaQ-00074y-SJ
 for bug-automake@HIDDEN; Tue, 16 Jun 2015 17:40:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eblake@HIDDEN>) id 1Z4yaN-00085M-Ds
 for bug-automake@HIDDEN; Tue, 16 Jun 2015 17:40:02 -0400
Received: from mx1.redhat.com ([209.132.183.28]:47438)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eblake@HIDDEN>)
 id 1Z4yaN-00085H-3S; Tue, 16 Jun 2015 17:39:59 -0400
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
 (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
 by mx1.redhat.com (Postfix) with ESMTPS id 4E7A28E689;
 Tue, 16 Jun 2015 21:39:58 +0000 (UTC)
Received: from [10.3.113.115] (ovpn-113-115.phx2.redhat.com [10.3.113.115])
 by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 t5GLdvK3003971; Tue, 16 Jun 2015 17:39:57 -0400
Message-ID: <558097A8.9050504@HIDDEN>
Date: Tue, 16 Jun 2015 15:39:52 -0600
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Gang Chen <gchengordon@HIDDEN>,
 "m4-discuss@HIDDEN" <m4-discuss@HIDDEN>, bug-automake@HIDDEN
Subject: Re: Can m4 be built without automake?
References: <CAAQ-hCfVuEGBT-3Ej+8zjL_45+bZvbhXD-fY0wzPvC0OMrmZ7w@HIDDEN>	<557F32B4.3020204@HIDDEN>
 <CAAQ-hCcOTtpkiqv7E0bOxpOfFttc=UQczBgKEasEBXrTvBWVZQ@HIDDEN>
In-Reply-To: <CAAQ-hCcOTtpkiqv7E0bOxpOfFttc=UQczBgKEasEBXrTvBWVZQ@HIDDEN>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="fxRUI1gBjfT4Hrw4OgCRCmKEUermFuG09"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fxRUI1gBjfT4Hrw4OgCRCmKEUermFuG09
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[re-adding the list, with permission]
[adding bug-automake]
[please don't top-post on technical lists]

On 06/16/2015 02:45 PM, Gang Chen wrote:
> Hi Eric,
>=20
> Thanks for the quick answer.
>=20
> What I'm trying to do is investigating if m4 can be built on the linux =
like
> os on IBM mainframe. I don't have m4, autoconf or automake on the syste=
m. I
> assumed m4 source code can be built without autoconf and or automake ju=
st
> as you suggested. But when I check the Makfile generated by ./configure=
, I
> see aclocal-1.14 is required, which is part of automake. You may check =
the
> Makefile attached.

It should indeed be possible to build m4 1.4.17 from a tarball without
having m4, autoconf, or automake already on the system.  Although I've
stripped the makefile, I see that it contains the following:

# Makefile.in generated by automake 1.14 from Makefile.am.
=2E..
PACKAGE_VERSION =3D 1.4.17

which is the case when you are building from the 1.4.17 tarball.  Good -
you are not trying to build a development version from .git.  That
tarball should not require the autotools to be pre-installed, and even
if you botched timestamps on files when unpacking the tarball, the
package includes the 'missing' script which is supposed to work around
that situation (that is, the 'missing' script is what is supposed to let
the build proceed normally even when automake-1.14 is not present).

>=20
> FSUM7351 is an error code, which means " You attempted to execute a com=
mand
> that could not be found". (
> http://www-01.ibm.com/support/docview.wss?uid=3Dswg21396470). So the er=
ror
> actually tells us automake is not available on my system, which is true=
=2E So
> I suspect it's not a automake problem but a problem in the configure
> script, which uses automake for some purpose.

All I can conclude, then, is that you somehow botched file timestamps
when unpacking the tarball, and that you have triggered some problem in
the 'missing' script that is unable to recover gracefully, even though
it is supposed to work just fine.  Since 'missing' is a shell script
shipped by automake, you may have better luck debugging why it failed on
your system, and/or asking for help on the automake list to figure out
why the build is failing even though 'missing' is being properly invoked.=


>>> make  all-recursive
>>> Making all in .
>>> CDPATH=3D"${ZSH_VERSION+.}:" && cd . && /bin/sh
>>> /plex/gordonc/work/m4-1.4.17/build-aux/missing aclocal-1.14 -I m4
>>> aclocal-1.14: /plex/gordonc/work/m4-1.4.17/build-aux/missing 81: FSUM=
7351
>>> not found

This says that 'make' ran 'missing', and missing properly determined
that 'aclocal-1.14' is not present...

>>
>> This says that the 'missing' script was trying to run a program named
>> FSUM7351, which doesn't exist.  Based on later transcript lines...
>>
>>> WARNING: 'aclocal-1.14' is missing on your system.
>>>          You should only need it if you modified 'acinclude.m4' or
>>>          'configure.ac' or m4 files included by 'configure.ac'.
>>>          The 'aclocal' program is part of the GNU Automake package:
>>>          <http://www.gnu.org/software/automake>
>>>          It also requires GNU Autoconf, GNU m4 and Perl in order to r=
un:
>>>          <http://www.gnu.org/software/autoconf>
>>>          <http://www.gnu.org/software/m4/>
>>>          <http://www.perl.org/>
>>> FSUM8226 make: Error code 127

=2E..but that missing exited with status 127 instead of status 0.  Hmm.
Reading automake's NEWS, I see this:

> New in 1.13:
> ...
> * Automatic remake rules and 'missing' script:
>=20
>   - The 'missing' script no longer tries to update the timestamp of
>     out-of-date files that require a maintainer-specific tool to be
>     remade, in case the user lacks such a tool (or has a too-old versio=
n
>     of it).  It just gives a useful warning, and in some cases also a
>     tip about how to obtain such a tool.
>=20
>   - The missing script has thus become useless as a (poor) way to work
>     around the sketched-timestamps issues that can happen for projects
>     that keep generated files committed in their VCS repository.  Such
>     projects are now encouraged to write a custom "fix-timestamps.sh"
>     script to avoid such issues; a simple example is provided in the
>     "CVS and generated files" chapter of the automake manual.

Yuck.  This is a regression in behavior in upstream automake.  It means
that any automake-generated file that is unpacked with timestamp skew
will now fail to build, instead of the old behavior of faking things and
exiting with status 0.  This in turn grinds the 'make' run to a halt,
where it used to succeed.

Oh, and it points out an automake doc bug:
https://www.gnu.org/software/automake/manual/automake.html#CVS has a
mention of 'fix-timestamp.sh', but not 'fix-timestamps.sh' as called out
in NEWS.

I'd still be interested in figuring out how you managed to botch
timestamps when unpacking your tarball; can you show a fine-grained
listing of the timestamps in your working directory that is resulting in
make thinking aclocal has to be re-run?  Does your file system have
sub-second granularity?  Does your version of 'make' consider a file as
up-to-date or out-of-date if it is the same timestamp as its
prerequisite?  Once you have diagnosed where the timestamp skew is
coming from, does the advice on the automake page of running these steps
allow you to then build?

> #!/bin/sh
> # fix-timestamp.sh: prevents useless rebuilds after "cvs update"
> sleep 1
> # aclocal-generated aclocal.m4 depends on locally-installed
> # '.m4' macro files, as well as on 'configure.ac'
> touch aclocal.m4
> sleep 1
> # autoconf-generated configure depends on aclocal.m4 and on
> # configure.ac
> touch configure
> # so does autoheader-generated config.h.in
> touch config.h.in
> # and all the automake-generated Makefile.in files
> touch `find . -name Makefile.in -print`
> # finally, the makeinfo-generated '.info' files depend on the
> # corresponding '.texi' files
> touch doc/*.info

Another thing to try: can you unpack an older GNU m4 tarball, one that
was generated with automake 1.12 or newer (1.4.16 should fit the bill),
and see if that builds just fine, because it used the older semantics of
'missing' that don't kill the build?  If so, another thing to try to
pinpoint the 'missing' script as the culprit would be to reproduce the
unpacking timestamp skews in both 1.4.16 and 1.4.17 working directories,
but then swap the 'missing' script between the two trees, before trying
to build, and see if the swap causes the build failure to migrate to the
build tree with the newer version of 'missing'.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--fxRUI1gBjfT4Hrw4OgCRCmKEUermFuG09
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJVgJeoAAoJEKeha0olJ0NqhZMH/0XuX2pl9QmCmNGCQbleXscd
3j5/JeCDuWw8z3ixXT/Wt9b2A8oU185GIt1g0o1/4rSrPRMdUd/7Xyt5Nzxj6Pnq
QPS+tAlBPXt6oxgPALsu6xBuLr6TQugMkwihkbosnGTMfsOqJ9ce5aUwy31B//aj
DuwL5r4c00i9g+yfRquNxsTKJ/Jp5MrTTN0jW+RXp25uXVCzUX1g/FjkHYT9O1aN
Oczzaf6XWjzs/RyRnz6Szsxs/44sb57yCGkreTfujP1StXWXe2q92zzI3xzEJCbo
tyIwCjbTke5cxGpryHZ/Znq/EKAD8N9B4U1UqphwwqaCUTFK4839RN5M9eOE3GQ=
=eD81
-----END PGP SIGNATURE-----

--fxRUI1gBjfT4Hrw4OgCRCmKEUermFuG09--




Acknowledgement sent to Eric Blake <eblake@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-automake@HIDDEN. Full text available.
Report forwarded to bug-automake@HIDDEN:
bug#20831; Package automake. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.