error: version mismatch. This is Automake 1.15.1 but the definition ... comes from Automake 1.14.1

1
votes

Yet another Autotools problem... I'm working on Fedora 27 and I am trying to build libidn and libidn2. I need configure; make; make install to actually work. The machines I need it to work on only have Autoconf, Automake, Autopoint, Libtool and compiler tools. They don't have anything else, like <something>2html or <something>2pdf so I cannot build documentation. I also cannot run autoreconf per the manual because that is broken too.

I don't know why the tools try to build the docs because I disable them with --disable-gtk-doc --disable-gtk-doc-html --disable-gtk-doc-pdf. I've tried to work around it with HELP2MAN=true and MAKEINFO=true, but Autotools finds another way to break:

gmake[2]: Entering directory '/home/Build-Scripts/libidn-1.33/doc'
echo '# This file is automatically generated.  DO NOT EDIT!          -*- makefile -*-' > Makefile.gdoc
echo >> Makefile.gdoc
echo 'gdoc_TEXINFOS =' >> Makefile.gdoc
echo 'gdoc_MANS =' >> Makefile.gdoc
echo >> Makefile.gdoc
for file in ../lib/idna.c ../lib/nfkc.c ../lib/pr29.c ../lib/punycode.c ../lib/stringprep.c ../lib/tld.c ../lib/toutf8.c ../lib/version.c ../lib/idn-free.c ../lib/strerror-idna.c ../lib/strerror-pr29.c ../lib/strerror-punycode.c ../lib/strerror-stringprep.c ../lib/strerror-tld.c; do \
  shortfile=`basename $file`; \
  echo "#" >> Makefile.gdoc; \
  echo "### $shortfile" >> Makefile.gdoc; \
  echo "#" >> Makefile.gdoc; \
  echo "gdoc_TEXINFOS += texi/$shortfile.texi" >> Makefile.gdoc; \
  echo "texi/$shortfile.texi: $file" >> Makefile.gdoc; \
  echo 'TABmkdir -p `dirname $@`' | sed "s/TAB/ /" >> Makefile.gdoc; \
  echo 'TAB$(PERL) ./gdoc -texinfo $(GDOC_TEXI_EXTRA_ARGS) $< > $@' | sed "s/TAB/       /" >> Makefile.gdoc; \
  echo >> Makefile.gdoc; \
  functions=`perl ./gdoc -listfunc $file`; \
  for function in $functions; do \
    echo "# $shortfile: $function" >> Makefile.gdoc; \
    echo "gdoc_TEXINFOS += texi/$function.texi" >> Makefile.gdoc; \
    echo "texi/$function.texi: $file" >> Makefile.gdoc; \
    echo 'TABmkdir -p `dirname $@`' | sed "s/TAB/       /" >> Makefile.gdoc; \
    echo 'TAB$(PERL) ./gdoc -texinfo $(GDOC_TEXI_EXTRA_ARGS) -function'" $function"' $< > $@' | sed "s/TAB/     /" >> Makefile.gdoc; \
    echo >> Makefile.gdoc; \
    echo "gdoc_MANS += man/$function.3" >> Makefile.gdoc; \
    echo "man/$function.3: $file" >> Makefile.gdoc; \
    echo 'TABmkdir -p `dirname $@`' | sed "s/TAB/       /" >> Makefile.gdoc; \
    echo 'TAB$(PERL) ./gdoc -man $(GDOC_MAN_EXTRA_ARGS) -function'" $function"' $< > $@' | sed "s/TAB/  /" >> Makefile.gdoc; \
    echo >> Makefile.gdoc; \
  done; \
  echo >> Makefile.gdoc; \
done
gmake Makefile
gmake[3]: Entering directory '/home/Build-Scripts/libidn-1.33/doc'
 cd .. && automake --gnu doc/Makefile
configure.ac:25: error: version mismatch.  This is Automake 1.15.1,
configure.ac:25: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:25: comes from Automake 1.14.1.  You should recreate
configure.ac:25: aclocal.m4 with aclocal and run automake again.
gmake[3]: *** [Makefile:1494: Makefile.in] Error 63
gmake[3]: Leaving directory '/home/Build-Scripts/libidn-1.33/doc'
gmake[2]: *** [Makefile:2205: Makefile.gdoc] Error 2
gmake[2]: Leaving directory '/home/Build-Scripts/libidn-1.33/doc'
gmake[1]: *** [Makefile:1333: all-recursive] Error 1
gmake[1]: Leaving directory '/home/Build-Scripts/libidn-1.33'
gmake: *** [Makefile:1235: all] Error 2

I find it incredibly hard to believe Automake-1.14 is required; and Automake-1.15 cannot be used. I don't care about the package version checks so I want to try to skip them next.

How do I fix this problem?

Stepping back to 10,000 feet, does Autotools have anyone with user interface experience to provide input for some of their decisions? Or, what is so broken with Autotools that they feel the need to break my build because my version of Automake is newer than the package was configured with? Who is the idiot who made that brilliant decision?

Here is how it is configured:

    PKG_CONFIG_PATH="/usr/local/lib64/pkgconfig" \
    CPPFLAGS="-I/usr/local/include -DNDEBUG" \
    CFLAGS= -m64 -march=native -fPIC" \
    CXXFLAGS= -m64 -march=native -fPIC" \
    LDFLAGS="-L/usr/local/lib64 -m64 -Wl,-R,/usr/local/lib64 -Wl,--enable-new-dtags" \
    LIBS="-ldl -lpthread" \
./configure --prefix="/usr/local" --libdir="/usr/local/lib64" \
    --enable-shared
    # --disable-gtk-doc --disable-gtk-doc-html --disable-gtk-doc-pdf

Here is how make is called:

MAKE_FLAGS=("-j" "$MAKE_JOBS")
MAKE_FLAGS+=("ACLOCAL=aclocal")
MAKE_FLAGS+=("AUTOCONF=autoconf")
MAKE_FLAGS+=("AUTOHEADER=autoheader")
MAKE_FLAGS+=("AUTOMAKE=automake")
MAKE_FLAGS+=("PERL=perl")
MAKE_FLAGS+=("HELP2MAN=true")
MAKE_FLAGS+=("MAKEINFO=true")

if ! "$MAKE" "${MAKE_FLAGS[@]}"
then
    echo "Failed to build IDN"
    [[ "$0" = "${BASH_SOURCE[0]}" ]] && exit 1 || return 1
fi
2
autotoolsautomake
Not my DV, by the way. – John Bollinger

2 Answers

9
votes

This message:

This is Automake 1.15.1 but the definition … comes from Automake 1.14.1

... says that Automake is running, which is not an ordinary part of configure; make; make install. As I've said before, you should prefer to avoid rebuilding the build system if possible, and often it is indeed possible. The Autotools are primarily for the package maintainer, not for package builders. In principle, builders just use the artifacts that the maintainer created via the Autotools.

I'm working on Fedora 27 and I am trying to build libidn and libidn2. I need configure; make; make install to actually work. The machines I need it to work on only have Autoconf, Automake, Autopoint and Libtool. They don't have anything else so I cannot run autoreconf because that is broken too.

For example, I just grabbed the Fedora 27 source RPM for libidn (v 1.33), used it to unpack a copy of the source distribution on my CentOS 7 machine, changed to the resulting directory, and performed a successful ./configure; make (but did not attempt make install). Autoconf and Automake are installed on my machine, but did not run, as was my expectation.

However, if the Autotools are in fact installed on the build machine, and if their inputs (configure.ac, Makefile.am, etc.) appear to be newer than their outputs (configure, Makefile.in, etc.), then an Autotools-derived build system may indeed try to rebuild those outputs (i.e. rebuild itself). This is likely to require some help if different versions of the Autotools are present on the build machine than were used to prepare the build system in the first place.

When that does not just work -- typically because of an Autotools version mismatch -- the usual recourse is to run autoreconf --install --force. It's not clear to me how or why your autoreconf is broken so as to prevent that. On Fedora 27, autoreconf is packaged together with autoconf, so if you have the latter then you should also have the former. Nevertheless, autoreconf is just a convenience wrapper around several other tools. You don't really need it. For example, you should be able to update the Automake-related pieces of your build system via the command

automake -f -c

. You would want to follow that up by running Autoconf:

autoconf -f

As a possible alternative, if the Autotools inputs in fact have not been modified, then perhaps you just have a timestamping problem. In that case you could try to fix the problem there, maybe with something like this:

find . -name configure -o name config.status -o name Makefile.in \
  | xargs touch

I find it incredibly hard to believe Automake-1.14 is required; and Automake-1.15.1 cannot be used. I don't care about the package version checks so I want to try to skip them next.

That's fine, because no version of Automake is required as part of a normal build of the package for any supported platform. Which platforms are "supported" is primarily a function of the build system, not of the Autotools themselves, so results do vary depending on the skill and foresight of the person who built that system. And you do care about the particular package version check you describe, because ignoring or suppressing it carries a high risk of leading to Automake and / or Autoconf outputs that do not work properly.

The Autotools help more than perhaps you realize in providing multi-platform support, but they cannot automagically ensure universal support. Neither can alternatives such as CMake or Scons.

Stepping back to 10,000 feet, does Autotools have anyone with user interface experience to provide input for some of their decisions? Or, what is so broken with Autotools that they feel the need to break my build because my version of Automake is newer than the package was configured with? Who is the idiot who made that brilliant decision?

I am sorry, again, that you are having difficulty. But the Autotools cannot break your build because they are not involved in your build. The Autotools are used, by someone operating in a package maintainer role, to build the package's build system. If the resulting build system does not adequately serve the machine and configuration on which you are trying to build the package, then that is not the fault of the Autotools.

Inasmuch as you seem to be porting a large number of Autotools-based packages to an environment that their build systems do not support, yes, you have exposure to the Autotools that people who just build packages for supported environments do not have. I am inclined to think that you somehow get more exposure than is necessary, but that's a separate issue. In any case, you are operating in a package-maintenance mode, and you need to look at the situation from that perspective. You're not just building the packages.

0
votes

Here is how I fixed it. it worked for both libidn and libidn2.

First, download and unpack libidn{2}. Then cd into the appropriate directory.

Second, fix the top level configure.ac file. This is referenced by something called gdoc even though things are configured without documentation:

# Fix AM_INIT_AUTOMAKE
sed -e 's/^AM_INIT_AUTOMAKE.*/AM_INIT_AUTOMAKE/g' configure.ac > configure.ac.fixed
mv configure.ac.fixed configure.ac
# Remove useless directive
sed -e '/AM_SILENT_RULES/d' configure.ac > configure.ac.fixed
mv configure.ac.fixed configure.ac
# Get rid of all docs Makefiles
sed -e '/^  doc\//d' configure.ac > configure.ac.fixed
mv configure.ac.fixed configure.ac
# Set time in the past to avoid re-configuration
touch -t 197001010000 configure.ac

Third, configure libidn{2} as required.

Fourth, fix individual Makefiles. This step removes the doc/ directories in for/each calls during recursive make:

for mfile in $(find "$PWD" -name Makefile);
do
    # Get rid of all docs directories
    sed -e 's| doc | |g' "$mfile" > "$mfile.fixed"
    mv "$mfile.fixed" "$mfile"
done

Fifth, run make.