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ć.

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.

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 

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ę.

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.

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.

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 .

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).

Problemem nie jest automakepakiet, tylko repozytorium

sudo apt-get install automake

Wersja instalacyjna aclocal-1.4, dlatego nie możesz znaleźć1.5 (w Ubuntu 14,15)

Użyj tego skryptu, aby zainstalować najnowszy https://github.com/gp187/nginx-builder/blob/master/fix/aclocal.sh

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!