bug#20831: Can m4 be built without automake?

[Eric Blake]

[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,
> 
> Thanks for the quick answer.
> 
> 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 system. I
> assumed m4 source code can be built without autoconf and or automake just
> 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.
...
PACKAGE_VERSION = 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).

> 
> FSUM7351 is an error code, which means " You attempted to execute a command
> that could not be found". (
> http://www-01.ibm.com/support/docview.wss?uid=swg21396470). So the error
> actually tells us automake is not available on my system, which is true. 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="${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: FSUM7351
>>> 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 run:
>>>          <http://www.gnu.org/software/autoconf>
>>>          <http://www.gnu.org/software/m4/>
>>>          <http://www.perl.org/>
>>> FSUM8226 make: Error code 127

...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:
> 
>   - 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 version
>     of it).  It just gives a useful warning, and in some cases also a
>     tip about how to obtain such a tool.
> 
>   - 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'.

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

signature.asc
Description: OpenPGP digital signature