127

Im trying to run a c++ program on github. (available at the following link https://github.com/mortehu/text-classifier)

I have a mac, and am trying to run it in the terminal. I think I have downloaded autoconf and automake but am not sure. To run the program I am going to the correct folder in terminal then running

./configure && make 

But I get the error:

WARNING: 'aclocal-1.15' 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/ make: *** [aclocal.m4] Error 127

I have xcode and g++ and all the things required to run c programs, but as is probably obvious, I have no idea what Im doing.

What is the easiest, simplest way to run the program in the above link? I realise it comes with a readme and example usage but I can not get that to work.

jww
  • 97,681
  • 90
  • 411
  • 885
Liam Flynn
  • 2,009
  • 3
  • 17
  • 16
  • 1
    You can get the autotools from http://brewformulas.org/Automake or https://lists.gnu.org/archive/html/automake/2007-05/msg00010.html – maddouri Oct 22 '15 at 10:34
  • 1
    "all the things required to run c programs" -- you need all the things to *compile* the program, which in this case includes the packages `automake`, `autoconf`, `m4`, and `perl`, as the message quite clearly states... "I think I have downloaded autoconf and automake but am not sure" -- I'm pretty sure you haven't *installed* it properly at the very least. ;-) – DevSolar Oct 22 '15 at 10:39

11 Answers11

241

Before running ./configure try running autoreconf -f -i. The autoreconf program automatically runs autoheader, aclocal, automake, autopoint and libtoolize as required.

Edit to add: This is usually caused by checking out code from Git instead of extracting it from a .zip or .tar.gz archive. In order to trigger rebuilds when files change, Git does not preserve files' timestamps, so the configure script might appear to be out of date. As others have mentioned, there are ways to get around this if you don't have a sufficiently recent version of autoreconf.

Another edit: This error can also be caused by copying the source folder extracted from an archive with scp to another machine. The timestamps can be updated, suggesting that a rebuild is necessary. To avoid this, copy the archive and extract it in place.

hr87
  • 1,775
  • 1
  • 11
  • 17
mortehu
  • 3,470
  • 2
  • 19
  • 14
  • Thanks Mortehu! But I then get the error: In file included from base/columnfile.cc:1: ./base/columnfile.h:8:10: fatal error: 'kj/debug.h' file not found #include Am I missing a file? – Liam Flynn Oct 22 '15 at 20:26
  • 1
    Yes, you are missing libkj, which is part of the Cap'n Proto project. You'll also need libsnappy. – mortehu Oct 23 '15 at 01:27
  • Okay, I finally have all the neccessary tools to configure, make and make install. It seems to all work, but where does the executable go? Not sure if this is important or relevant, but I get the following message (as part of a much larger message) when I do make install : # Not a target: install: # Command-line target. # Implicit rule search has not been done. # Modification time never checked. # File has not been updated. Does this mean no output file is created? – Liam Flynn Oct 24 '15 at 13:36
  • The program should end up as `tools/text-classifier/text-classifier`. I don't know why `make install` doesn't work. – mortehu Oct 24 '15 at 23:10
  • this might happen if you run ./configure in your project and then update `automake` package – Alec Istomin Apr 06 '19 at 21:15
  • Great explanation why, but this is bug anyway. – Daniel Katz Aug 29 '22 at 12:58
69

Often, you don't need any auto* tools and the simplest solution is to simply run touch aclocal.m4 configure in the relevant folder (and also run touch on Makefile.am and Makefile.in if they exist). This will update the timestamp of aclocal.m4 and remind the system that aclocal.m4 is up-to-date and doesn't need to be rebuilt. After this, it's probably best to empty your build directory and rerun configure from scratch after doing this. I run into this problem regularly. For me, the root cause is that I copy a library (e.g. mpfr code for gcc) from another folder and the timestamps change.

Of course, this trick isn't valid if you really do need to regenerate those files, perhaps because you have manually changed them. But hopefully the developers of the package distribute up-to-date files.


And of course, if you do want to install automake and friends, then use the appropriate package-manager for your distribution.


Install aclocal which comes with automake:

brew install automake          # for Mac
apt-get install automake       # for Ubuntu

Try again:

./configure && make 
Aaron McDaid
  • 26,501
  • 9
  • 66
  • 88
Emil Laine
  • 41,598
  • 9
  • 101
  • 157
  • After doing that I get: configure.ac:25: error: Autoconf version 2.69 or higher is required ... WARNING: 'aclocal-1.15' is probably too old. ... make: *** [aclocal.m4] Error 63 – Liam Flynn Oct 22 '15 at 12:14
  • and then after installing autoconf v2.69 I get : libtool: Version mismatch error. This is libtool 2.4.2 Debian-2.4.2-1.11, but the libtool: definition of this LT_INIT comes from libtool 2.4.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 Debian-2.4.2-1.11 libtool: and run autoconf again. – Liam Flynn Oct 22 '15 at 12:28
  • Make sure you have done `brew install libtool`, then run `aclocal`, then run `autoconf`. – Emil Laine Oct 22 '15 at 12:33
  • I updated libtool but now I get: libtool: Version mismatch error. This is libtool 2.4.2 Debian-2.4.2-1.11, but the libtool: definition of this LT_INIT comes from libtool 2.4.6. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 Debian-2.4.2-1.11 libtool: and run autoconf again. – Liam Flynn Oct 22 '15 at 12:56
  • This solves the problem. But it is not necessary as it requires many other things (root privilege, network connection, more space for new software etc.). Solution by Droopycon below is (near to) a proper answer as Error message clearly says that "You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'.". – harihardik May 28 '16 at 11:32
  • Hi folks, I've just edited the answer. I intended to make a very small change, but it grew too much. In hindsight, perhaps I should have added a new answer. My goal is to arrive at a more comprehensive answer describing a number of solutions. For example, `brew` is a mac-only solution. This question is now the top hit in search engines for the `automake-1.15: command not found` error, so it's good to cover Linux also – Aaron McDaid Oct 14 '16 at 10:39
  • `touch aclocal.m4 configure`: nope – user124384 Aug 13 '17 at 21:44
  • Worked for me. Thanks so much. – Arjun J Rao Jan 12 '22 at 07:25
  • `touch acinclude.m4 aclocal.m4 configure` `touch Makefile.am Makefile.in` But config.h was incomplete after all ... – NorbertM Aug 15 '23 at 15:22
17

You can install the version you need easily:

First get source:

$ wget https://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz

Unpack it:

$ tar -xzvf automake-1.15.tar.gz

Build and install:

$ cd automake-1.15
$ ./configure  --prefix=/opt/aclocal-1.15
$ make
$ sudo mkdir -p /opt
$ sudo make install

Use it:

$ export PATH=/opt/aclocal-1.15/bin:$PATH
$ aclocal --version

aclocal (GNU automake) 1.15

Now when aclocal is called, you get the right version.

  • This installed "aclocal" for me. I installed it via CygWin's UI Installer by searching for "automake" and selecting version 11-1. – justdan23 Nov 13 '19 at 01:45
14

A generic answer that may or not apply to this specific case:

As the error message hint at, aclocal-1.15 should only be required if you modified files that were used to generate aclocal.m4

If you don't modify any of those files (including configure.ac) then you should not need to have aclocal-1.15.

In my case, the problem was not that any of those files was modified but somehow the timestamp on configure.ac was 6 minutes later compared to aclocal.m4.

I haven't figured out why, but a clean clone of my git repo solved the issue for me. Maybe something linked to git and how it created files in the first place.

Rather than rerunning autoconf and friends, I would just try to get a clean clone and try again.

It's also possible that somebody committed a change to configure.ac but didn't regenerate the aclocal.m4, in which case you indeed have to rerun automake and friends.

Fattie
  • 27,874
  • 70
  • 431
  • 719
Droopycom
  • 1,831
  • 1
  • 17
  • 20
  • 1
    More appropriate answer. I got the similar error because I did not extract source files from tar which is provided by squid. Instead I copied already extracted folder and my order of copying file was different which caused error. I simply re-extracted from tar directly and it started working. I would mark solution by Droopycon a proper answer, given a chance. – harihardik May 28 '16 at 11:30
  • Brilliant! I had used `rsync` to copy the already-extracted files from one server to another (instead of copying the compressed source archives), without preserving the timestamps. When I copied the source archives instead, and extracted them on the target machine, the problem did not occur. Thank you! – Ben Johnson Aug 01 '17 at 19:33
  • Indeed, very often the answer is "Checkout the repo fresh". Fantastic answer and bounty! – Fattie Nov 21 '17 at 11:40
9

The whole point of Autotools is to provide an arcane M4-macro-based language which ultimately compiles to a shell script called ./configure. You can ship this compiled shell script with the source code and that script should do everything to detect the environment and prepare the program for building. Autotools should only be required by someone who wants to tweak the tests and refresh that shell script.

It defeats the point of Autotools if GNU This and GNU That has to be installed on the system for it to work. Originally, it was invented to simplify the porting of programs to various Unix systems, which could not be counted on to have anything on them. Even the constructs used by the generated shell code in ./configure had to be very carefully selected to make sure they would work on every broken old shell just about everywhere.

The problem you're running into is due to some broken Makefile steps invented by people who simply don't understand what Autotools is for and the role of the final ./configure script.

As a workaround, you can go into the Makefile and make some changes to get this out of the way. As an example, I'm building the Git head of GNU Awk and running into this same problem. I applied this patch to Makefile.in, however, and I can sucessfully make gawk:

diff --git a/Makefile.in b/Makefile.in

index 5585046..b8b8588 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -312,12 +312,12 @@ distcleancheck_listfiles = find . -type f -print

 # Directory for gawk's data files. Automake supplies datadir.
 pkgdatadir = $(datadir)/awk
-ACLOCAL = @ACLOCAL@
+ACLOCAL = true
 AMTAR = @AMTAR@
 AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
-AUTOCONF = @AUTOCONF@
-AUTOHEADER = @AUTOHEADER@
-AUTOMAKE = @AUTOMAKE@
+AUTOCONF = true
+AUTOHEADER = true
+AUTOMAKE = true
 AWK = @AWK@
 CC = @CC@
 CCDEPMODE = @CCDEPMODE@

Basically, I changed things so that the harmless true shell command is substituted for all the Auto-stuff programs.

The actual build steps for Gawk don't need the Auto-stuff! It's only involved in some rules that get invoked if parts of the Auto-stuff have changed and need to be re-processed. However, the Makefile is structured in such a way that it fails if the tools aren't present.

Before the above patch:

$ ./configure
[...]
$ make gawk
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/kaz/gawk/missing aclocal-1.15 -I m4
/home/kaz/gawk/missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' 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/>
make: *** [aclocal.m4] Error 127

After the patch:

$ ./configure
[...]
$ make gawk
CDPATH="${ZSH_VERSION+.}:" && cd . && true -I m4
CDPATH="${ZSH_VERSION+.}:" && cd . && true
gcc -std=gnu99 -DDEFPATH='".:/usr/local/share/awk"' -DDEFLIBPATH="\"/usr/local/lib/gawk\"" -DSHLIBEXT="\"so"\" -DHAVE_CONFIG_H -DGAWK -DLOCALEDIR='"/usr/local/share/locale"' -I.     -g -O2 -DNDEBUG -MT array.o -MD -MP -MF .deps/array.Tpo -c -o array.o array.c 
[...]
gcc -std=gnu99  -g -O2 -DNDEBUG  -Wl,-export-dynamic -o gawk array.o awkgram.o builtin.o cint_array.o command.o debug.o dfa.o eval.o ext.o field.o floatcomp.o gawkapi.o gawkmisc.o getopt.o getopt1.o int_array.o io.o main.o mpfr.o msg.o node.o profile.o random.o re.o regex.o replace.o str_array.o symbol.o version.o      -ldl -lm
$ ./gawk --version
GNU Awk 4.1.60, API: 1.2
Copyright (C) 1989, 1991-2015 Free Software Foundation.
[...]

There we go. As you can see, the CDPATH= command lines there are where the Auto-stuff was being invoked, where you see the true commands. These report successful termination, and so it just falls through that junk to do the darned build, which is perfectly configured.

I did make gawk because there are some subdirectories that get built which fail; the trick has to be repeated for their respective Makefiles.

If you're running into this kind of thing with a pristine, official tarball of the program from its developers, then complain. It should just unpack, ./configure and make without you having to patch anything or install any Automake or Autoconf materials.

Ideally, a pull of their Git head should also behave that way.

Kaz
  • 55,781
  • 9
  • 100
  • 149
  • Why do you assume the Makefiles are broken? As pointed out in emlai's answer the build system recognizes that the dependencies for the generated files are out-of-date (which may only be the case of screwed-up timestamps which you can fix by `touch`ing them). Saying that the people that created this system doesn't understand what it was created for (ensuring that you build correct with all dependencies - which **includes** the `auto*`-parts if they are changed) and changing the Makefiles to effectively don't do this completely any more seems ... wrong. – Simon Sobisch Sep 01 '17 at 07:28
  • @SimonSobisch Are you having this problem and not able to use the answer? – Kaz Sep 01 '17 at 14:31
  • Thank you for asking. No, I'm not having this problem but from reading your post I see the bottom line "this error occurs because the Makefiles are broken and not what Makefiles should be" - while the Makefiles are *exactly* doing what they should (rebuilding files that need to be rebuild according to the same rules an object file would be rebuild from a C source). In most cases the error occurs because people use non-dist packages without the necessary tools or the time-stamps from the sources are broken "complain to the author". – Simon Sobisch Sep 01 '17 at 20:21
  • 1
    I'd *never* recommend to change a tool to `true`. If you really want to fix the parts that are broken "just because the timestamps" better run `make --touch` against the failing targets (if you want to gather them run `make --keep-going` to get a list of the "broken" parts beforehand). – Simon Sobisch Sep 01 '17 at 20:28
  • 1
    @SimonSobisch Great suggestions; sounds like you have the beginnings of a separate answer there. In this case changing the tools to `true` is rationally justified by the fact that those tools are unnecessary to build the program, but only to rebuild the `configure` script, which is already available in prebuilt form. Touching the timestamps to suppress attempts to run the tools achieves the same effect. – Kaz Sep 01 '17 at 21:04
  • @SimonSobish If software fails to build because of timestamps, it is broken. We should be able to unpack a tarball such that the current time stamp is used for every file and it should configure and build. The steps for updating the "autostuff" materials should be confined to their own make target(s) that are not pulled into the dependency graph of the main target. Or else, a more robust system should be used for detecting whether the configure meta-materials have changed, such SHA digests. – Kaz Sep 03 '17 at 03:06
8

I think the touch command is the right answer e.g. do something like

touch --date="`date`" aclocal.m4 Makefile.am configure Makefile.in

before [./configure && make].

Sidebar I: Otherwise, I agree with @kaz: adding dependencies for aclocal.m4 and/or configure and/or Makefile.am and/or Makefile.in makes assumptions about the target system that may be invalid. Specifically, those assumptions are

1) that all target systems have autotools,

2) that all target systems have the same version of autotools (e.g. automake.1.15 in this case).

3) that if either (1) or (2) are not true for any user, that the user is extracting the package from a maintainer-produced TAR or ZIP format that maintains timestamps of the relevant files, in which case all autotool/configure/Makefile.am/Makefile.in dependencies in the configure-generated Makefile will be satisfied before the make command is issued.

The second assumption fails on many Mac systems because automake.1.14 is the "latest" for OSX (at least that is what I see in MacPorts, and apparently the same is true for brew).

The third assumption fails spectacularly in a world with Github. This failure is an example of an "everyone thinks they are normative" mindset; specifically, the maintainers, who are the only class of users that should need to edit Makefile.am, have now put everyone into that class.

Perhaps there is an option in autowhatever that keeps these dependencies from being added to Makefile.in and/or Makefile.

Sidebar II [Why @kaz is right]: of course it is obvious, to me and other cognoscenti, to simply try a sequence of [touch] commands to fool the configure-created Makefile from re-running configure and the autotools. But that is not the point of configure; the point of configure is to ensure as many users on as many different systems as as possible can simply do [./configure && make] and move on; most users are not interested in "shaving the yak" e.g. debugging faulty assumptions of the autotools developers.

Sidebar III: it could be argued that ./configure, now that autotools adds these dependencies, is the wrong build tool to use with Github-distributed packages.

Sidebar IV: perhaps configure-based Github repos should put the necessary touch command into their readme, e.g. https://github.com/drbitboy/Tycho2_SQLite_RTree.

Brian Carcich
  • 391
  • 2
  • 8
5

2018, yet another solution ...

https://github.com/apereo/mod_auth_cas/issues/97

in some cases simply running

$ autoreconf -f -i

and nothing else .... solves the problem.

You do that in the directory /pcre2-10.30 .

What a nightmare.

(This usually did not solve the problem in 2017, but now usually does seem to solve the problem - they fixed something. Also, it seems your Dockerfile should now usually start with "FROM ibmcom/swift-ubuntu" ; previously you had to give a certain version/dev-build to make it work.)

Community
  • 1
  • 1
Fattie
  • 27,874
  • 70
  • 431
  • 719
3

The problem is not automake package, is the repository

sudo apt-get install automake

Installs version aclocal-1.4, that's why you can't find 1.5 (In Ubuntu 14,15)

Use this script to install latest https://github.com/gp187/nginx-builder/blob/master/fix/aclocal.sh

Pian0_M4n
  • 2,505
  • 31
  • 35
0

2017 - High Sierra

It is really hard to get autoconf 1.15 working on Mac. We hired an expert to get it working. Everything worked beautifully.

Later I happened to upgrade a Mac to High Sierra.

The Docker pipeline stopped working!

Even though autoconf 1.15 is working fine on the Mac.

How to fix,

Short answer, I simply trashed the local repo, and checked out the repo again.

This suggestion is noted in the mix on this QA page and elsewhere.

It then worked fine!

It likely has something to do with the aclocal.m4 and similar files. (But who knows really). I endlessly massaged those files ... but nothing.

For some unknown reason if you just scratch your repo and get the repo again: everything works!

I tried for hours every combo of touching/deleting etc etc the files in question, but no. Just check out the repo from scratch!

Community
  • 1
  • 1
Fattie
  • 27,874
  • 70
  • 431
  • 719
  • To get an automake repo back to its checkout state you can do: "make distclean". – Frederick Ollinger Dec 01 '17 at 21:13
  • Technically it is not a git command. It's to clean up a repository after a ./configure. So it's part of automake. But it should work on any git repository which uses automake. – Frederick Ollinger Dec 01 '17 at 22:51
  • gotchya, that sounds like a great tip. – Fattie Dec 01 '17 at 23:35
  • *"It is really hard to get autoconf 1.15 working on Mac. We hired an Ultra-Expert to get it working..."* - That tells us how broken this toolchain is. And sadly, in 20+ years, it has not been fixed. Not fixing it is the thing I take exception to. What purpose does it serve to leave it broke so people cannot use it? – jww Jan 03 '18 at 04:46
0

If an autotools project is being distributed using git and you are responsible for distributing it, it can be helpful to have AM_MAINTAINER_MODE in the configure.ac file. This prevents the automatic updating of the autotools system using timestamp checking, and therefore prevents this error.

When AM_MAINTAINER_MODE is in configure.ac then by default, maintainer mode is off, which is desirable for the end users who are building the project. If AM_MAINTAINER_MODE(enable) is in configure.ac, the opposite behaviour will be used - and maintainer mode will be enabled by default thereby reintroducing this error.

For reference, you can see how AM_MAINTAINER_MODE is used in the binutils-gdb repository:

AC_INIT
AC_CONFIG_MACRO_DIRS([.. ../config])
AC_CONFIG_SRCDIR([main.c])
AC_CONFIG_HEADERS(config.h:config.in, [echo > stamp-h])
AM_MAINTAINER_MODE

AC_PROG_CC
AC_PROG_CXX
# snip

Note that by modifying configure.ac you will need to run autoreconf locally - this answer is only applicable if you have autotools on your machine, but not some other machines that you want to be able to build on.

Related: How do I prevent autotools from re-generating configure script automatically?

Ciaran Woodward
  • 146
  • 2
  • 11
0

...I encountered the same error while running "make deps" on Blender source, a very quick fix is to copy the version you have, on my OS 1.16, to the searched version: sudo cp /usr/bin/aclocal-1.16 /usr/bin/aclocal-1.15 sudo cp /usr/bin/automake-1.16 usr/bin/automake-1.15

After having passed the problem (here failing to compile flex), I deleted the copy: sudo rm /usr/bin/automake-1.15 /usr/bin/aclocal-1.15

Note that to compile Blender you should not "make deps" but follow for example the instructions say for uBuntu https://wiki.blender.org/wiki/Building_Blender/Linux/Ubuntu

  • 1
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community May 12 '23 at 10:44