часто, вам не нужны никакие auto* инструменты и самое простое решение-просто запустить touch aclocal.m4 configure в соответствующей папке (а также запустите touch on Makefile.am и Makefile.in если они существуют). Это обновит метку aclocal.m4 и напомните системе, что aclocal.m4 до-до-даты и не должен быть восстановлен. После этого, вероятно, лучше всего очистить ваш

общий ответ, который может применяться или не применяться к этому конкретному случаю:

как намек на сообщение об ошибке, aclocal-1.15 должен потребоваться только в том случае, если вы изменили файлы, которые использовались для создания aclocal.М4

Если вы не изменяете ни один из этих файлов (включая configure.ac) тогда вам не нужно иметь aclocal-1.15.

в моем случае проблема заключалась не в том, что какой-либо из этих файлов был изменен, а в том, что временная метка на configure.ac был 6 минут спустя по сравнению с aclocal.М4.

Я не понял, почему, но чистый клон моего git repo решил проблему для меня. Возможно, что-то связанное с git и как он создал файлы в первую очередь.

вместо того, чтобы перезапускать autoconf и друзей, я бы просто попробуйте получить чистый клон и повторите попытку.

также возможно, что кто-то совершил изменение для настройки.ac, но не регенерировал aclocal.m4, в этом случае вам действительно нужно перезапустить automake и друзей.

весь смысл Autotools заключается в предоставлении тайного языка M4-macro, который в конечном итоге компилируется в сценарий оболочки под названием ./configure. Вы можете отправить этот скомпилированный сценарий оболочки с исходным кодом, и этот сценарий должен сделать все, чтобы обнаружить среду и подготовить программу к созданию. Autotools должен требоваться только тем, кто хочет настроить тесты и обновить этот сценарий оболочки.

это побеждает точку Autotools, если GNU это и GNU, который имеет быть установленным в системе для его работы. Первоначально он был изобретен для упрощения переноса программ в различные системы Unix, на которые нельзя было рассчитывать. Даже конструкции, используемые сгенерированным кодом оболочки в ./configure должен был быть очень тщательно отобран, чтобы убедиться, что они будут работать на каждой сломанной старой оболочке почти везде.

проблема, с которой вы сталкиваетесь, связана с некоторыми сломанными шагами Makefile, изобретенными людьми, которые просто не поймите, что такое Autotools и роль final ./configure сценарий.

в качестве обходного пути вы можете зайти в Makefile и внести некоторые изменения, чтобы избавиться от этого. Например, я создаю git-голову GNU Awk и сталкиваюсь с этой же проблемой. Я применил этот патч к Makefile.in, однако, и я могу успешно make gawk:

дифф --ГИТ в/make-файл.в б/make-файл.в

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@

в основном, я изменил вещи так, что безвредные true команда shell заменяется на все программы Auto-stuff.

фактические шаги сборки для Gawk не нуждаются в авто-материале! Он участвует только в некоторых правилах, которые вызываются, если части автоматического материала изменились и должны быть повторно обработаны. Однако Makefile структурирован таким образом, что он терпит неудачу, если инструменты отсутствуют.

перед вышеуказанным патчем:

$ ./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

после патча:

$ ./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.
[...]

там мы идем. Как видите, the CDPATH= командные строки там, где вызывался автоматический материал, где вы видите true команды. Они сообщают об успешном завершении, и поэтому он просто падает через этот мусор, чтобы сделать проклятую сборку, которая отлично настроена.

я make gawk потому что есть некоторые подкаталоги, которые, не, фокус должен быть повторен для своих файлов Makefile.

если вы сталкиваетесь с такого рода вещами с нетронутым, официальным архив программы от ее разработчиков, потом жалуются. Он должен просто распаковать,./configure и make без патч или устанавливать какие-либо материалы или использующих automake autoconf для.

в идеале, тяга их головы Git также должна вести себя таким образом.

вы можете легко установить нужную вам версию:

сначала вам источник:

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

распаковать его:

$ tar -xzvf automake-1.15.tar.gz

сборка и установка:

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

использовать:

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

aclocal (GNU automake) 1.15

теперь, когда aclocal вызывается, вы получаете правильную версию.

2018, Еще одно решение ...

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

на в некоторых случаях просто работает

$ autoreconf -f -i

и больше ничего .... решить проблему.

Вы делаете это в директории /pcre2-10.30 .

Какой кошмар.

(обычно это делалось не решить проблему в 2017 году, но теперь обычно тут кажется, решить проблему - они что-то починили. Кроме того, кажется, что ваш Dockerfile теперь должен обычно начинаться с "от ibmcom/swift-ubuntu" ; ранее вам нужно было дать определенную версию/dev-build, чтобы она работала.)

проблема не automake пакет, является репозиторием

sudo apt-get install automake

установка версии aclocal-1.4, вот почему вы не можете найти 1.5 (В Ubuntu 14,15)

используйте этот скрипт для установки последней версии https://github.com/gp187/nginx-builder/blob/master/fix/aclocal.sh

2017 - Высокая Сьерра

очень сложно заставить autoconf 1.15 работать на Mac. Мы наняли эксперта, чтобы заставить его работать. Все работало прекрасно.

позже мне довелось обновить Mac до High Sierra.

трубопровод Докера перестал работать!

хотя autoconf 1.15 is отлично работает на Mac.

Как исправить,

короткий ответ, я просто разгромил местное РЕПО и проверил РЕПО снова.

это предложение отмечено в миксе на этой странице QA и в других местах.

он тогда работал нормально!

Он-то С aclocal.М4 и подобные файлы (или кто знает). Я бесконечно массировал их, но ничего.

по неизвестной причине, если вы просто почесать РЕПО и РЕПО: все работает!

Я пробовал часами каждую комбинацию касания / удаления и т. д. и т. д. Файлы, о которых идет речь, но нет. Просто проверьте РЕПО с нуля!

Я думаю, что команда touch является правильным ответом, например, сделать что-то вроде

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

перед [./настроить && сделать].

Sidebar I: в противном случае я согласен с @kaz: добавление зависимостей для aclocal.m4 и/или настроить и / или Makefile.am и / или Makefile.in делает предположения о целевой системе, которые могут быть недействительными. В частности, эти предположения

1) что все целевые системы имеют autotools,

2), что все конечные системы та же версия autotools (например, automake.1.15 в данном случае).

3) что если (1) или (2) не верны для любого пользователя, что пользователь извлекает пакет из формата tar или ZIP, созданного сопровождающим, который поддерживает временные метки соответствующих файлов, в этом случае все autotool/configure/Makefile.am / Makefile.в зависимостях в configure-generated Makefile будет удовлетворяться до выдается команда make.

второе предположение не на многих системах Mac, потому что automake.1.14 является "последним" для OSX (по крайней мере, это то, что я вижу в MacPorts, и, по-видимому, то же самое верно для brew).

третье предположение эффектно терпит неудачу в мире с GitHub. Эта неудача является примером установки" все думают, что они нормативны"; в частности, сопровождающие, которые являются только класс пользователей, которым необходимо отредактировать Makefile.am, теперь поставили все в класс.

возможно, в autowhatever есть опция, которая не позволяет добавлять эти зависимости в Makefile.В и / или Makefile.

Sidebar II [Почему @kaz прав]: конечно, для меня и других знатоков очевидно просто попробовать последовательность команд [touch], чтобы обмануть созданный Makefile из повторного запуска configure и autotools. Но это не точка configure; точка configure заключается в том, чтобы обеспечить столько пользователей на стольких разных системах как можно проще можно сделать [./ configure & & make] и двигаться дальше; большинство пользователей не заинтересованы в "бритье яка", например, отладка ошибочных предположений разработчиков autotools.

Sidebar III: можно утверждать, что ./configure теперь, когда autotools добавляет эти зависимости, является неправильным инструментом сборки для использования с распределенными пакетами Github.

Sidebar IV: возможно, основанные на настройке репозитории Github должны поместить необходимую команду touch в свой readme, например https://github.com/drbitboy/Tycho2_SQLite_RTree.