GNOME Bugzilla – Bug 700350
Building glib requires automake and autoconf
Last modified: 2013-06-22 13:29:32 UTC
Building glib 2.36.2 or 2.37.0 fails if automake and autoconf are not installed. From a MacPorts buildbot failure log: https://build.macports.org/builders/buildports-mtln-x86_64/builds/4752/steps/compile/logs/stdio make[2]: Entering directory `/opt/local/var/macports/build/_opt_mports_dports_devel_glib2/glib2/work/glib-2.36.2/docs' Making all in reference make[3]: Entering directory `/opt/local/var/macports/build/_opt_mports_dports_devel_glib2/glib2/work/glib-2.36.2/docs/reference' Making all in glib make[4]: Entering directory `/opt/local/var/macports/build/_opt_mports_dports_devel_glib2/glib2/work/glib-2.36.2/docs/reference/glib' cd ../../.. && /bin/sh /opt/local/var/macports/build/_opt_mports_dports_devel_glib2/glib2/work/glib-2.36.2/missing automake-1.13 --gnu docs/reference/glib/Makefile /opt/local/var/macports/build/_opt_mports_dports_devel_glib2/glib2/work/glib-2.36.2/missing: line 81: automake-1.13: command not found WARNING: 'automake-1.13' is missing on your system. You should only need it if you modified 'Makefile.am' or 'configure.ac' or m4 files included by 'configure.ac'. The 'automake' 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/> make[4]: *** [Makefile.in] Error 127 This is unexpected because we have not modified Makefile.am, configure.ac or the m4 files.
And now that automake in MacPorts has been updated to 1.13.2, the build complains that this is too new: configure.ac:66: error: version mismatch. This is Automake 1.13.2, configure.ac:66: but the definition used by this AM_INIT_AUTOMAKE configure.ac:66: comes from Automake 1.13.1. You should recreate configure.ac:66: aclocal.m4 with aclocal and run automake again. https://trac.macports.org/ticket/39246
Our developer Joshua Root found that the cause of the problem is that your gtk-doc.make file has a newer mtime than your Makefile.in files.
Same here, trying to build glib on a fedora 18 machine. A touch on every Makefile.in files in docs/reference/gobject gio gio/gdbus-object-manager-example glib fixes the compilation.
FYI, here's the command I've run before make: find -type f -name Makefile.in -exec touch {} \;
*** Bug 701486 has been marked as a duplicate of this bug. ***
I encountered this too, and came to same conclusion as comment #2. Makefile.in for some Makefile.am's that include gtk-doc.make have timestamp a bit older than gtk-doc.make, causing attempt to regenerate Makefile.in. That success only if system automake is same version than one used in tarball creation system (1.13.1). Other versions complain about incompatibility.
This appears to step from our use of BUILT_EXTRA_DIST: BUILT_EXTRA_DIST += \ README \ INSTALL \ ChangeLog \ config.h.win32 \ gtk-doc.make which results in this happening during 'make dist': make[2]: Entering directory `/home/desrt/code/glib' GEN ChangeLog cd . && /bin/sh ./config.status config.h.win32 config.status: creating config.h.win32 files='README INSTALL ChangeLog config.h.win32 gtk-doc.make'; \ for f in $files; do \ if test -f $f; then d=.; else d=.; fi; \ rm -f glib-2.37.2/$f && cp $d/$f glib-2.37.2 || exit 1; done make[2]: Leaving directory `/home/desrt/code/glib' note 'cp' without -a or anything, so we get a fresh timestamp on the file.
This happened here: https://git.gnome.org/browse/glib/commit/?id=0192c599377c35cc465eed1ae61de56d5a1034e8 I don't know why this change was made. I searched for bug activity on glib, gtk+ and gtk-doc around the time of the change, but nothing relevant turned up. Meanwhile, reverting that change seems to fix the issue -- I get a gtk-doc.make in the built tarball that has the same timestamp as the one from my system.
Created attachment 246122 [details] [review] Makefile.am: move gtk-doc.make back to EXTRA_DIST 0192c599377c35cc465eed1ae61de56d5a1034e8 moved this file from EXTRA_DIST TO BUILT_EXTRA_DIST for an unknown reason. Having it here causes the timestamp to be updated during 'make dist' to something newer than docs/reference/*/Makefile.in. This is a problem because those Makefile.in are generated by including gtk-doc.make, so automake becomes convinced that they need to be regenerated. This is a problem for people who don't have automake installed, or have the wrong version. The timestamp problem has been around for quite a while, but it only became a problem recently after automake changed policy about this in commit a22717dffe37f30ef2ad2c355b68c9b3b5e4b8c7. Specifically: --- a/lib/missing +++ b/lib/missing ... -exit 0 +# Propagate the correct exit status (expected to be 127 for a program +# not found, 63 for a program that failed due to version mismatch). +exit $st the 'missing' script that wrapped the automake call to request regeneration of the Makefile previously returned 0 in the event of an error, but now returns a non-zero status, which aborts the build. In any case, it makes no sense for us to dist a gtk-doc.make that's newer than the rest of our generated files so we can avoid the attempt at regeneration in the first place by just moving it to EXTRA_DIST.
Link to the automake commit mentioned in the log message: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=a22717dffe37f30ef2ad2c355b68c9b3b5e4b8c7
Perhaps the original commit was to work around some issue with old gtk-doc versions with srcdir != builddir builds? In any case, I have tested the fix with both tarball and git builds, and in tree and srcdir != builddir builds, and seemed to work fine in all cases.
Applying this then, since nobody else objects... Thanks for the report! Attachment 246122 [details] pushed as 15477eb - Makefile.am: move gtk-doc.make back to EXTRA_DIST