Jak obejść ostrzeżenie „brak 'aclocal-1.15' w twoim systemie”?

85

Próbuję uruchomić program C ++ na githubie. (dostępne pod następującym linkiem https://github.com/mortehu/text-classifier )

Mam Maca i próbuję go uruchomić w terminalu. Myślę, że pobrałem autoconf i automake, ale nie jestem pewien. Aby uruchomić program, przechodzę do odpowiedniego folderu w terminalu, a następnie uruchamiam

./configure && make 

Ale pojawia się błąd:

OSTRZEŻENIE: w systemie brakuje 'aclocal-1.15'. Powinieneś go potrzebować tylko wtedy, gdy zmodyfikowałeś pliki „acinclude.m4”, „configure.ac” lub m4 zawarte w pliku „configure.ac”. Program „aclocal” jest częścią pakietu GNU Automake: http://www.gnu.org/software/automake Do działania wymaga również oprogramowania GNU Autoconf, GNU m4 i Perl: http://www.gnu.org / software / autoconf http://www.gnu.org/software/m4/ http://www.perl.org/ make: *** [aclocal.m4] Błąd 127

Mam xcode i g ++ oraz wszystkie rzeczy potrzebne do uruchamiania programów w c, ale jak jest prawdopodobnie oczywiste, nie mam pojęcia, co robię.

Jaki jest najłatwiejszy, najprostszy sposób uruchomienia programu w powyższym linku? Zdaję sobie sprawę, że zawiera plik readme i przykładowe użycie, ale nie mogę tego uruchomić.

Liam Flynn
źródło
1
Narzędzia automatyczne można pobrać z brewformulas.org/Automake lub lists.gnu.org/archive/html/automake/2007-05/msg00010.html
maddouri
1
„wszystko, co potrzebne do uruchomienia programów c” - trzeba wszystkie rzeczy, aby skompilować program, który w tym przypadku zawiera pakiety automake, autoconf, m4, i perl, jak się komunikat wyraźnie stwierdza ... „Myślę, że pobrałeś autoconf i automake, ale nie jestem pewien ”- jestem prawie pewien, że przynajmniej nie zainstalowałeś go poprawnie. ;-)
DevSolar

Odpowiedzi:

168

Przed bieganiem ./configurespróbuj biegać autoreconf -f -i. Program autoreconf automatycznie uruchamia autoheader, aclocal, automake, autopoint i libtoolize zgodnie z wymaganiami.

Edytuj, aby dodać: Jest to zwykle spowodowane wyrejestrowaniem kodu z Gita zamiast wyodrębniania go z archiwum .ziplub .tar.gz. Aby wyzwolić odbudowę po zmianie plików, Git nie zachowuje sygnatur czasowych plików, więc configureskrypt może wydawać się nieaktualny. Jak wspominali inni, istnieją sposoby na obejście tego problemu, jeśli nie masz wystarczająco aktualnej wersji autoreconf.

Kolejna edycja: ten błąd może być również spowodowany skopiowaniem folderu źródłowego wyodrębnionego z archiwum za pomocą scp na inny komputer. Znaczniki czasu można aktualizować, co sugeruje, że konieczna jest przebudowa. Aby tego uniknąć, skopiuj archiwum i wypakuj je na miejscu.

mortehu
źródło
Dzięki, Mortehu! Ale potem pojawia się błąd: W pliku zawartym z base / columnfile.cc: 1: ./base/columnfile.h:8:10: błąd krytyczny: nie znaleziono pliku 'kj / debug.h' #include <kj / debug .h> Czy brakuje mi pliku?
Liam Flynn
1
Tak, brakuje ci libkj, które jest częścią projektu Cap'n Proto. Będziesz także potrzebować biblioteki libsnappy.
mortehu
Dobra, w końcu mam wszystkie niezbędne narzędzia do konfiguracji, tworzenia i instalacji. Wydaje się, że wszystko działa, ale gdzie idzie plik wykonywalny? Nie jestem pewien, czy jest to ważne lub istotne, ale otrzymuję następujący komunikat (jako część znacznie większej wiadomości), kiedy wykonuję instalację: # Nie jest celem: install: # Element docelowy wiersza poleceń. # Niejawne wyszukiwanie reguł nie zostało wykonane. # Czas modyfikacji nigdy nie sprawdzony. # Plik nie został zaktualizowany. Czy to oznacza, że ​​nie jest tworzony żaden plik wyjściowy?
Liam Flynn
Program powinien zakończyć się jako tools/text-classifier/text-classifier. Nie wiem, dlaczego make installnie działa.
mortehu
może się to zdarzyć, jeśli uruchomisz ./configure w swoim projekcie, a następnie zaktualizujesz automakepakiet
Alec Istomin
52

Często zdarza się, że nie potrzeba żadnych auto*narzędzi i najprostszym rozwiązaniem jest po prostu uruchomić touch aclocal.m4 configurew odpowiednim folderze (a także prowadzony touchna Makefile.ami Makefile.injeśli takie istnieją). Spowoduje to zaktualizowanie sygnatury czasowej aclocal.m4i przypomni systemowi, że aclocal.m4jest aktualny i nie trzeba go odbudowywać. Po wykonaniu tej czynności prawdopodobnie najlepiej będzie opróżnić buildkatalog i ponownie uruchomić go configureod zera. Regularnie napotykam ten problem. Dla mnie główną przyczyną jest to, że kopiuję bibliotekę (np. mpfrKod gcc) z innego folderu i zmieniają się sygnatury czasowe.

Oczywiście ta sztuczka nie jest poprawna, jeśli naprawdę musisz ponownie wygenerować te pliki, być może dlatego, że ręcznie je zmieniłeś. Miejmy jednak nadzieję, że twórcy pakietu rozpowszechniają aktualne pliki.


Oczywiście, jeśli chcesz zainstalować automakei mieć przyjaciół, użyj odpowiedniego menedżera pakietów dla swojej dystrybucji.


Zainstaluj aclocal, który jest dostarczany z automake:

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

Spróbuj ponownie:

./configure && make 
emlai
źródło
Po wykonaniu tej czynności otrzymuję: configure.ac:25: błąd: wymagany jest Autoconf w wersji 2.69 lub wyższej ... UWAGA: 'aclocal-1.15' jest prawdopodobnie za stary. ... make: *** [aclocal.m4] Błąd 63
Liam Flynn
a potem po zainstalowaniu autoconf v2.69 otrzymuję: libtool: błąd niezgodności wersji. To jest libtool 2.4.2 Debian-2.4.2-1.11, ale definicja libtool: tego LT_INIT pochodzi z libtool 2.4.4. libtool: Powinieneś ponownie utworzyć plik aclocal.m4 z makrami z libtool 2.4.2 Debian-2.4.2-1.11 libtool: i ponownie uruchomić autoconf.
Liam Flynn
Upewnij się, że skończyłeś brew install libtool, potem biegnij aclocal, a potem biegnij autoconf.
emlai
Zaktualizowałem libtool, ale teraz otrzymuję: libtool: błąd niezgodności wersji. To jest libtool 2.4.2 Debian-2.4.2-1.11, ale definicja libtool: tego LT_INIT pochodzi z libtool 2.4.6. libtool: Powinieneś ponownie utworzyć plik aclocal.m4 z makrami z libtool 2.4.2 Debian-2.4.2-1.11 libtool: i ponownie uruchomić autoconf.
Liam Flynn
To rozwiązuje problem. Ale nie jest to konieczne, ponieważ wymaga wielu innych rzeczy (uprawnienia roota, połączenie sieciowe, więcej miejsca na nowe oprogramowanie itp.). Poniższe rozwiązanie firmy Droopycon jest (prawie) poprawną odpowiedzią, ponieważ komunikat o błędzie wyraźnie mówi, że „Powinieneś go potrzebować tylko wtedy, gdy zmodyfikowałeś pliki 'acinclude.m4', 'configure.ac' lub m4 zawarte w 'configure.ac'." .
harihardik
11

Możesz łatwo zainstalować potrzebną wersję:

Najpierw pobierz źródło:

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

Rozpakuj to:

$ tar -xzvf automake-1.15.tar.gz

Zbuduj i zainstaluj:

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

Użyj tego:

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

aclocal (GNU automake) 1.15

Teraz, gdy zostanie wywołany aclocal, otrzymasz odpowiednią wersję.

Frederick Ollinger
źródło
To zainstalowało dla mnie „aclocal”. Zainstalowałem go przez Instalatora UI CygWin, wyszukując „automake” i wybierając wersję 11-1.
justdan23
8

Ogólna odpowiedź, która może odnosić się lub nie do tego konkretnego przypadku:

Jak wskazuje komunikat o błędzie, aclocal-1.15 powinien być wymagany tylko wtedy, gdy zmodyfikowałeś pliki, które zostały użyte do wygenerowania aclocal.m4

Jeśli nie zmodyfikujesz żadnego z tych plików (w tym configure.ac), nie powinieneś mieć aclocal-1.15.

W moim przypadku problem nie polegał na tym, że którykolwiek z tych plików został zmodyfikowany, ale w jakiś sposób sygnatura czasowa na configure.ac była 6 minut później w porównaniu z aclocal.m4.

Nie wiem, dlaczego, ale czysty klon mojego repozytorium git rozwiązał problem. Może coś związanego z gitem i tym, jak tworzyło pliki w pierwszej kolejności.

Zamiast ponownie uruchamiać autoconfa i znajomych, po prostu spróbuję uzyskać czysty klon i spróbować ponownie .

Możliwe jest również, że ktoś wprowadził zmianę w configure.ac, ale nie zregenerował pliku aclocal.m4, w takim przypadku rzeczywiście musisz ponownie uruchomić automake i znajomych.

Droopycom
źródło
1
Bardziej odpowiednia odpowiedź. Otrzymałem podobny błąd, ponieważ nie wyodrębniłem plików źródłowych z tar, który jest dostarczany przez squid. Zamiast tego skopiowałem już rozpakowany folder i moja kolejność kopiowania pliku była inna, co spowodowało błąd. Po prostu ponownie wyodrębniłem bezpośrednio z tar i zaczęło działać. Oceniłbym rozwiązanie Droopycon jako właściwą odpowiedź, mając szansę.
harihardik
Znakomity! Kiedyś rsynckopiowałem już rozpakowane pliki z jednego serwera na inny (zamiast kopiować skompresowane archiwa źródłowe) bez zachowywania znaczników czasu. Gdy zamiast tego skopiowałem archiwa źródłowe i rozpakowałem je na komputerze docelowym, problem nie wystąpił. Dziękuję Ci!
Ben Johnson
Rzeczywiście, bardzo często odpowiedź brzmi „Sprawdź repozytorium świeże”. Fantastyczna odpowiedź i nagroda!
Fattie
6

Celem Autotools jest dostarczenie tajemniczego języka opartego na makrach M4, który ostatecznie kompiluje się do skryptu powłoki o nazwie ./configure. Możesz wysłać ten skompilowany skrypt powłoki z kodem źródłowym, który powinien zrobić wszystko, aby wykryć środowisko i przygotować program do zbudowania. Narzędzia automatyczne powinny być wymagane tylko przez kogoś, kto chce poprawić testy i odświeżyć skrypt powłoki.

To pokonuje sens Autotools, jeśli GNU This i GNU That muszą być zainstalowane w systemie, aby działały. Pierwotnie został wymyślony, aby uprościć przenoszenie programów na różne systemy uniksowe, na które nie można było liczyć, że coś na nich będzie. Nawet konstrukcje używane przez wygenerowany kod powłoki w programie ./configuremusiały być bardzo starannie dobrane, aby mieć pewność, że będą działać na każdej uszkodzonej starej powłoce prawie wszędzie.

Problem, na który się natkniesz, jest spowodowany błędnymi krokami Makefile wymyślonymi przez ludzi, którzy po prostu nie rozumieją, do czego służy Autotools i jaką rolę odgrywa ostateczny ./configureskrypt.

Aby obejść ten problem, możesz przejść do pliku Makefile i wprowadzić pewne zmiany, aby usunąć to z drogi. Jako przykład buduję głowę Git GNU Awk i napotykam ten sam problem. Makefile.inJednak zastosowałem tę poprawkę do i mogę z powodzeniem 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@

Zasadniczo zmieniłem rzeczy tak, że nieszkodliwe truepolecenie powłoki zostało zastąpione przez wszystkie programy Auto-stuff.

Rzeczywiste kroki budowania Gawk nie wymagają elementów Auto! Dotyczy to tylko niektórych reguł, które są wywoływane, jeśli części elementów automatycznych uległy zmianie i wymagają ponownego przetworzenia. Jednak Makefile jest tak skonstruowany, że zawodzi, jeśli nie ma narzędzi.

Przed powyższą łatką:

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

Po patchu:

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

No to jedziemy. Jak widać, CDPATH=wiersze poleceń są tam, gdzie wywoływano funkcję Auto-stuff, gdzie widzisz truepolecenia. Zgłaszają pomyślne zakończenie, więc po prostu wypada przez te śmieci, aby zrobić cholerną kompilację, która jest doskonale skonfigurowana.

Zrobiłem to, make gawkponieważ są budowane podkatalogi, które nie działają; tę sztuczkę trzeba powtórzyć dla odpowiednich plików Makefile.

Jeśli napotkasz tego typu rzeczy z nieskazitelnym, oficjalnym plikiem tar programu od jego twórców, to narzekaj. Powinien po prostu rozpakować ./configurei makebez konieczności łatania czegokolwiek lub instalowania jakichkolwiek materiałów Automake lub Autoconf.

Idealnie byłoby, gdyby pociągnięcie głowy Gita również zachowywało się w ten sposób.

Kaz
źródło
Dlaczego zakładasz, że pliki Makefile są uszkodzone? Jak wskazano w odpowiedzi emlai, system kompilacji rozpoznaje, że zależności dla wygenerowanych plików są nieaktualne (może to być tylko przypadek zepsutych znaczników czasu, które można naprawić, touchużywając ich). Mówiąc, że ludzie, którzy stworzyli ten system nie rozumie, co to został stworzony dla (zapewnienie, że można zbudować poprawne ze wszystkimi zależnościami - który zawiera te auto*-parts jeśli są zmienione) i zmieniając Makefile skutecznie nie rób tego całkowicie dowolny więcej wydaje się ... złe.
Simon Sobisch
@SimonSobisch Czy masz ten problem i nie możesz użyć odpowiedzi?
Kaz
Dziękuję za pytanie. Nie, nie mam tego problemu, ale po przeczytaniu twojego posta widzę, że "ten błąd występuje, ponieważ pliki Makefile są zepsute, a nie takie, jakie powinny być" - podczas gdy pliki Makefiles robią dokładnie to, co powinny (odbudowywanie plików, które wymagają aby był odbudowany według tych samych reguł, plik obiektowy zostałby odbudowany ze źródła C). W większości przypadków błąd występuje, ponieważ ludzie używają pakietów non-dist bez niezbędnych narzędzi lub znaczniki czasu ze źródeł są łamane „narzekaj autora”.
Simon Sobisch
Nigdy nie polecałbym zmiany narzędzia na true. Jeśli naprawdę chcesz naprawić części, które są zepsute „tylko dlatego, że znaczniki czasu”, lepiej działają make --touchna nieudane cele (jeśli chcesz je zebrać, biegnij wcześniej, make --keep-goingaby uzyskać listę „zepsutych” części).
Simon Sobisch
@SimonSobisch Wspaniałe sugestie; brzmi tak, jakbyś miał tam początki oddzielnej odpowiedzi. W tym przypadku zmiana narzędzi na truejest racjonalnie uzasadniona faktem, że narzędzia te są zbędne do budowy programu, a jedynie do przebudowy configureskryptu, który jest już dostępny w gotowej formie. Dotknięcie znaczników czasu w celu powstrzymania prób uruchomienia narzędzi daje ten sam efekt.
Kaz
4

Myślę, że polecenie dotykowe jest właściwą odpowiedzią, np. Zrób coś takiego

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

przed [./configure && make].

Pasek boczny I: W przeciwnym razie zgadzam się z @kaz: dodając zależności dla aclocal.m4 i / lub configure i / lub Makefile.am i / lub Makefile.in przyjmuje założenia dotyczące systemu docelowego, które mogą być nieprawidłowe. W szczególności te założenia są

1) że wszystkie systemy docelowe mają automatyczne narzędzia,

2) że wszystkie systemy docelowe mają tę samą wersję narzędzi automatycznych (np. W tym przypadku automake.1.15).

3) że jeśli (1) lub (2) nie są prawdziwe dla żadnego użytkownika, oznacza to, że użytkownik wyodrębnia pakiet z formatu TAR lub ZIP utworzonego przez opiekuna, który przechowuje znaczniki czasu odpowiednich plików, w którym to przypadku wszystkie narzędzia automatyczne / konfiguracja Zależności /Makefile.am/Makefile.in w pliku Makefile wygenerowanym przez konfigurację zostaną spełnione przed wykonaniem polecenia make.

Drugie założenie zawodzi w wielu systemach Mac, ponieważ automake.1.14 jest „najnowszym” dla OSX (przynajmniej to widzę w MacPorts i podobno to samo dotyczy brew).

Trzecie założenie zawodzi spektakularnie w świecie z Githubem. Ta porażka jest przykładem nastawienia „każdy myśli, że jest normatywny”; konkretnie opiekunowie, którzy są jedyną klasą użytkowników, którzy powinni edytować Makefile.am, umieścili teraz wszystkich w tej klasie.

Być może jest opcja w autowh what, która powstrzymuje te zależności przed dodaniem do Makefile.in i / lub Makefile.

Pasek boczny II [Dlaczego @kaz ma rację]: oczywiście dla mnie i innych osób jest oczywiste, że po prostu wypróbujemy sekwencję poleceń [dotykowych], aby oszukać skonfigurowany plik Makefile od ponownego uruchomienia configure i autotools. Ale nie o to chodzi w konfiguracji; celem konfiguracji jest zapewnienie, aby jak najwięcej użytkowników na tak wielu różnych systemach mogło po prostu wykonać [./configure && make] i przejść dalej; większość użytkowników nie jest zainteresowana „goleniem jaka”, np. debugowaniem błędnych założeń twórców autotools.

Pasek boczny III: można argumentować, że ./configure, teraz, gdy autotools dodaje te zależności, jest niewłaściwym narzędziem do budowania, którego można używać z pakietami dystrybuowanymi na Github.

Pasek boczny IV: być może repozytoria Github oparte na konfiguracji powinny umieścić niezbędne polecenie dotykowe w swoim pliku readme, np . Https://github.com/drbitboy/Tycho2_SQLite_RTree .

Brian Carcich
źródło
4

2018, kolejne rozwiązanie ...

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

w niektórych przypadkach po prostu działa

$ autoreconf -f -i

i nic więcej .... nie rozwiązuje problemu.

Robisz to w katalogu /pcre2-10.30.

Co za koszmar.

(Zwykle tak było nie rozwiązuje problemu w 2017 roku, ale teraz zwykle nie wydają się rozwiązać ten problem - naprawiono coś Również wydaje swoją Dockerfile powinien zwykle zaczynają się od „Z ibmcom / SWIFT-ubuntu”; wcześniej trzeba było dać. pewna wersja / dev-build, aby działała).

Fattie
źródło
0

2017 - High Sierra

Naprawdę trudno jest uruchomić autoconf 1.15 na Macu. Zatrudniliśmy eksperta, aby to działało. Wszystko pięknie działało.

Później zdarzyło mi się uaktualnić Maca do High Sierra.

Potok Dockera przestał działać!

Chociaż autoconf 1.15 jest działa dobrze na komputerach Mac.

Jak naprawić,

Krótka odpowiedź, po prostu zniszczyłem lokalne repozytorium i ponownie sprawdziłem repozytorium.

Ta sugestia jest odnotowana w zestawieniu na tej stronie kontroli jakości i w innych miejscach.

Wtedy zadziałało dobrze!

Prawdopodobnie ma to coś wspólnego z aclocal.m4 i podobnymi plikami . (Ale kto tak naprawdę wie). Bez końca masowałem te pliki ... ale nic.

Z jakiegoś nieznanego powodu, jeśli po prostu podrapiesz swoje repozytorium i uzyskasz je ponownie: wszystko działa!

Próbowałem godzinami każdej kombinacji dotykania / usuwania itp. Plików, o których mowa, ale nie. Po prostu sprawdź repozytorium od zera!

Fattie
źródło
Aby przywrócić repozytorium automake do stanu kasy, możesz zrobić: "make distclean".
Frederick Ollinger
Technicznie nie jest to polecenie git. Ma to na celu wyczyszczenie repozytorium po ./configure. Więc to jest część automake. Ale powinno działać na każdym repozytorium git, które używa automake.
Frederick Ollinger
gotchya, to brzmi jak świetna wskazówka.
Fattie
„Naprawdę trudno jest uruchomić autoconf 1.15 na Macu. Zatrudniliśmy Ultra-eksperta, aby działał…” - To nam mówi, jak uszkodzony jest ten łańcuch narzędzi. Niestety od ponad 20 lat nie zostało to naprawione. Nie naprawianie tego jest rzeczą, od której biorę wyjątek. Jakiemu celowi służy pozostawienie go zepsutego, aby ludzie nie mogli go używać?
jww