Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002510graphvizBuild/Installpublic2015-01-20 20:092015-02-04 18:23
Reporterryandesign 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
Platformx86_64OSOS XOS Version10.10.2
Summary0002510: After autoreconf, build fails saying automake-1.14 was not found
DescriptionIn MacPorts, because of issue 0002509, we modify the configure.ac and Makefile.am files, then run autoreconf prior to configuring and building. This worked fine with autoconf 2.69, automake 1.14.1, and libtool 2.4.4.

On 2015-01-12, automake in MacPorts was updated to version 1.15: https://trac.macports.org/changeset/131474 [^]

This caused graphviz to fail to build, with a message that automake-1.14 could not be found:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_graphviz/graphviz/work/graphviz-2.38.0/config/missing: line 81: automake-1.14: command not found
WARNING: 'automake-1.14' 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/> [^]

For the complete log see https://trac.macports.org/ticket/46582 [^]

This is odd because the graphviz source code doesn't seem to mention a specific version of automake.

The libtool 2.4.4 source distribution includes a file aclocal.m4 which was itself built with aclocal from automake 1.14.1. This file gets installed at /opt/local/share/libtool/aclocal.m4. It contains lines like this:

# AM_AUTOMAKE_VERSION(VERSION)
# ----------------------------
# Automake X.Y traces this macro to ensure aclocal.m4 has been
# generated from the m4 files accompanying Automake X.Y.
# (This private macro should not be called outside this file.)
AC_DEFUN([AM_AUTOMAKE_VERSION],
[am__api_version='1.14'
dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
dnl require some minimum version. Point them to the right macro.
m4_if([$1], [1.14.1], [],
      [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
])

# _AM_AUTOCONF_VERSION(VERSION)
# -----------------------------
# aclocal traces this macro to find the Autoconf version.
# This is a private macro too. Using m4_define simplifies
# the logic in aclocal, which can simply ignore this definition.
m4_define([_AM_AUTOCONF_VERSION], [])

# AM_SET_CURRENT_AUTOMAKE_VERSION
# -------------------------------
# Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
# This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
[AM_AUTOMAKE_VERSION([1.14.1])dnl
m4_ifndef([AC_AUTOCONF_VERSION],
  [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
_AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])

Upgrading to libtool 2.4.5, released 2015-01-19, fixes the problem, and I've requested this here: https://trac.macports.org/ticket/46635 [^]

libtool 2.4.5's aclocal.m4 was built with aclocal from automake 1.15 and contains these lines:

# AM_AUTOMAKE_VERSION(VERSION)
# ----------------------------
# Automake X.Y traces this macro to ensure aclocal.m4 has been
# generated from the m4 files accompanying Automake X.Y.
# (This private macro should not be called outside this file.)
AC_DEFUN([AM_AUTOMAKE_VERSION],
[am__api_version='1.15'
dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
dnl require some minimum version. Point them to the right macro.
m4_if([$1], [1.15], [],
      [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
])

# _AM_AUTOCONF_VERSION(VERSION)
# -----------------------------
# aclocal traces this macro to find the Autoconf version.
# This is a private macro too. Using m4_define simplifies
# the logic in aclocal, which can simply ignore this definition.
m4_define([_AM_AUTOCONF_VERSION], [])

# AM_SET_CURRENT_AUTOMAKE_VERSION
# -------------------------------
# Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
# This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
[AM_AUTOMAKE_VERSION([1.15])dnl
m4_ifndef([AC_AUTOCONF_VERSION],
  [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
_AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])

The graphviz source includes two copies of aclocal.m4—one in the root directory, which was built with aclocal from automake 1.13.4, and one in the libltdl directory which was built with aclocal from automake 1.11.1.

I do not understand the autotools well enough to understand whether this is an autotools bug, or a graphviz bug, or my bug for doing something wrong.
TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT
FORMER-ID
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT
VERSION2.39.20150120.0545
Attached Files

- Relationships

-  Notes
User avatar (0000867)
ellson (administrator)
2015-01-21 09:27

The nightly builds from GIT sources use the script:
   ./autogen.sh; make dist
on a fedora-20 host to make the tar.gz archive that is the basis of all the builds. So the version of automake in the tar.gz is whatever fedora-20 has.

This script uses:
    autoreconf -v --install --force
which forces the replacement of the aclocal, automake and libtool components.

aclocal.m4 and libltdl/ are not saved in GIT.
User avatar (0000873)
ryandesign (reporter)
2015-02-04 18:23

We are already using "autoreconf -fvi". In trying to determine whether using "./autogen.sh" instead would help, it became apparent that the issue is intermittent. Others have observed this as well, as reported in the MacPorts tickets, and even some of our automated build servers experience the problem while others do not. I have not seen similar problems with any other software package, only with graphviz, which is why I suspected this is a graphviz build system bug. The problem occurs intermittently even when not building in parallel.

- Issue History
Date Modified Username Field Change
2015-01-20 20:09 ryandesign New Issue
2015-01-21 09:27 ellson Note Added: 0000867
2015-02-04 18:23 ryandesign Note Added: 0000873


MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker