Comment surmonter "" il manque "'aclocal-1.15' sur votre système"?
J'essaie de lancer un programme c ++ sur github. (disponible sur le lien suivant https://github.com/mortehu/text-classifier )
J'ai un mac et j'essaye de l'exécuter dans le terminal. Je pense avoir téléchargé autoconf et automake mais je ne suis pas sûr. Pour exécuter le programme, je vais dans le bon dossier dans le terminal, puis je lance
./configure && make
Mais je reçois l'erreur:
AVERTISSEMENT: "aclocal-1.15" est manquant sur votre système. Vous ne devriez en avoir besoin que si vous avez modifié les fichiers "acinclude.m4", "configure.ac" ou m4 inclus dans "configure.ac". Le programme 'aclocal' fait partie du package GNU Automake: http://www.gnu.org/software/automake Il nécessite également GNU Autoconf, GNU m4 et Perl pour pouvoir exécuter: http://www.gnu.org/software/autoconfhttp://www.gnu.org/software/m4/http : //www.Perl.org/ make: *** [aclocal.m4] Erreur 127
J'ai xcode et g ++ et tout ce qui est nécessaire pour exécuter des programmes c, mais comme cela est probablement évident, je ne sais pas du tout ce que je fais.
Quel est le moyen le plus simple et le plus simple d'exécuter le programme via le lien ci-dessus? Je me rends compte que cela vient avec un readme et un exemple d'utilisation, mais je ne peux pas le faire fonctionner.
Avant de lancer ./configure essayez de lancer autoreconf -f -i. Le programme autoreconf exécute automatiquement autoheader, aclocal, automake, autopoint et libtoolize selon les besoins.
Modifier pour ajouter: Ceci est généralement causé par l'extraction du code de Git au lieu de l'extraire d'une archive .Zip ou .tar.gz. Afin de déclencher des reconstructions lorsque les fichiers changent, Git ne conserve pas les horodatages des fichiers. Le script configure peut donc sembler obsolète. Comme d'autres l'ont mentionné, il existe des moyens de contourner ce problème si vous ne disposez pas d'une version suffisamment récente de autoreconf.
Another edit: Cette erreur peut aussi être causée par la copie du dossier source extrait d'une archive avec scp sur une autre machine. Les horodatages peuvent être mis à jour, suggérant qu'une reconstruction est nécessaire. Pour éviter cela, copiez l'archive et extrayez-la à la place.
Souvent, vous n'avez besoin d'aucun outil _auto*_ et la solution la plus simple consiste simplement à exécuter _touch aclocal.m4 configure_ dans le dossier approprié (et également à exécuter touch sur _Makefile.am_ et _Makefile.in_ si elles existent). Ceci mettra à jour l'horodatage de _aclocal.m4_ et rappellera au système que _aclocal.m4_ est à jour et qu'il n'est pas nécessaire de le reconstruire. Après cela, il est probablement préférable de vider votre répertoire build et de réexécuter configure à partir de zéro. Je rencontre ce problème régulièrement. Pour moi, la cause première est que je copie une bibliothèque (par exemple, mpfr code pour gcc) à partir d'un autre dossier et que les horodatages changent.
Bien sûr, cette astuce n’est pas valable si vous avez vraiment besoin de régénérer ces fichiers, peut-être parce que vous les avez modifiés manuellement. Mais espérons que les développeurs du paquet distribuent des fichiers à jour.
Et bien sûr, si vous voulez installer automake et amis, utilisez le gestionnaire de paquets approprié pour votre distribution.
Installez aclocal fourni avec automake:
_brew install automake # for Mac
apt-get install automake # for Ubuntu
_Réessayer:
_./configure && make
_Une réponse générique qui peut ou non s'appliquer à ce cas particulier:
Comme le message d'erreur l'indique, aclocal-1.15 ne devrait être requis que si vous avez modifié les fichiers utilisés pour générer aclocal.m4.
Si vous ne modifiez aucun de ces fichiers (y compris configure.ac), vous n'avez pas besoin d'avoir aclocal-1.15.
Dans mon cas, le problème n'était pas qu'aucun de ces fichiers n'avait été modifié, mais que l'horodatage sur configure.ac était 6 minutes plus tard comparé à aclocal.m4.
Je n'ai pas compris pourquoi, mais un clone propre de mon dépôt git a résolu le problème pour moi. Peut-être que quelque chose est lié à git et à la manière dont il a créé des fichiers.
Plutôt que de relancer autoconf et ses amis, je voudrais essayez d’obtenir un clone pur et essayez à nouvea.
Il est également possible que quelqu'un ait commis une modification de configure.ac mais n'a pas régénéré le fichier aclocal.m4, auquel cas vous devez en effet réexécuter automake et ses amis.
L'objectif principal d'Autotools est de fournir un langage arcanique basé sur une macro M4 qui se compile finalement en un script Shell appelé ./configure. Vous pouvez expédier ce script Shell compilé avec le code source. Ce script doit tout faire pour détecter l'environnement et préparer le programme à la construction. Les outils automatiques ne devraient être requis que par quelqu'un qui souhaite modifier les tests et actualiser ce script Shell.
Cela annule le point d'Autotools si GNU This et GNU doivent être installés sur le système pour que cela fonctionne. A l'origine, il avait été inventé pour simplifier le portage de programmes sur divers systèmes Unix, sur lesquels on ne pouvait compter pour rien. Même les constructions utilisées par le code Shell généré dans ./configure devaient être soigneusement sélectionnées pour être sûr qu'elles fonctionneraient sur tous les anciens Shell cassés un peu partout.
Le problème que vous rencontrez est dû à des étapes Makefile cassées inventées par des personnes qui ne comprennent tout simplement pas à quoi sert Autotools et le rôle du script final ./configure.
En guise de solution de contournement, vous pouvez aller dans le Makefile et faire quelques changements pour éliminer ce problème. Par exemple, je construis la tête Git de GNU Awk et je rencontre ce même problème. J'ai appliqué ce patch à Makefile.in, cependant, et je peux avec succès 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@
En gros, j'ai changé les choses pour que la commande inoffensive true Shell remplace tous les programmes de remplissage automatique.
Les étapes de construction de Gawk n’ont pas besoin de la fonction Auto-stuff! Certaines règles ne sont invoquées que si des parties de la substance auto ont été modifiées et doivent être retraitées. Cependant, le Makefile est structuré de manière à échouer si les outils ne sont pas présents.
Avant le patch ci-dessus:
$ ./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
Après le 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.
[...]
Nous y voilà. Comme vous pouvez le constater, les lignes de commande CDPATH= se trouvent là où la substance auto était invoquée, où vous voyez les commandes true. Celles-ci signalent une terminaison réussie, et il est donc impossible de créer une construction douteuse parfaitement configurée.
J'ai fait make gawk parce qu'il y a des sous-répertoires construits qui échouent; L'astuce doit être répétée pour leurs Makefiles respectifs.
Si vous rencontrez ce genre de problème avec une archive vierge et officielle du programme fournie par ses développeurs, plaignez-vous. Il devrait simplement décompresser, ./configure et make sans que vous ayez à appliquer de correctif ni à installer de matériel Automake ou Autoconf.
Idéalement, une traction de la tête de leur Git devrait également se comporter de cette façon.
2018, encore une autre solution ...
https://github.com/apereo/mod_auth_cas/issues/97
dans certains cas simplement en cours d'exécution
$ autoreconf -f -i
et rien d'autre… ne résout le problème.
Vous faites cela dans le répertoire /pcre2-10.30.
Quel cauchemard.
(Cela a généralement pas résolu le problème en 2017, mais maintenant, habituellement le fait semblent résoudre le problème - ils ont corrigé quelque chose. De plus, il semble que votre fichier Docker devrait maintenant commencer habituellement par "FROM ibmcom/Swift-ubuntu"; auparavant, vous deviez utiliser une version/dev-build pour le faire fonctionner).
Vous pouvez installer la version dont vous avez besoin facilement:
D'abord obtenir la source:
$ wget https://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz
Déballez le:
$ tar -xzvf automake-1.15.tar.gz
Construire et installer:
$ cd automake-1.15
$ ./configure --prefix=/opt/aclocal-1.15
$ make
$ Sudo mkdir -p /opt
$ Sudo make install
Utilise le:
$ export PATH=/opt/aclocal-1.15/bin:$PATH
$ aclocal --version
aclocal (GNU automake) 1.15
Maintenant, quand aclocal est appelé, vous obtenez la bonne version.
Je pense que la commande tactile est la bonne réponse, par exemple. faire quelque chose comme
touch --date="`date`" aclocal.m4 Makefile.am configure Makefile.in
avant [./configure && make].
Barre latérale I: Sinon, je suis d'accord avec @kaz: l'ajout de dépendances pour aclocal.m4 et/ou configure et/ou Makefile.am et/ou Makefile.in émet des hypothèses sur le système cible susceptibles d'être invalides. Plus précisément, ces hypothèses sont
1) que tous les systèmes cibles disposent d’autotools,
2) que tous les systèmes cibles ont la même version d’autotools (par exemple, automake.1.15 dans ce cas).
3) que si (1) ou (2) ne sont pas vrais pour un utilisateur, que l'utilisateur extrait le package à partir d'un format TAR ou Zip produit par le mainteneur qui conserve les horodatages des fichiers pertinents, auquel cas tous les outils autotool/configure Les dépendances /Makefile.am/Makefile.in dans le Makefile généré par configure seront satisfaites avant que la commande ne soit émise.
La deuxième hypothèse échoue sur de nombreux systèmes Mac car automake.1.14 est la "dernière" pour OSX (du moins, c'est ce que je vois dans MacPorts, et il en va apparemment de même pour brasser).
La troisième hypothèse échoue de façon spectaculaire dans un monde avec Github. Cet échec est un exemple d'un état d'esprit "tout le monde se croit normatif"; en particulier, les responsables, qui sont la seule classe des utilisateurs devant éditer le fichier Makefile.am, ont maintenant mis tout le monde dans cette classe.
Peut-être y at-il une option dans autowther qui empêche l’ajout de ces dépendances à Makefile.in et/ou Makefile.
Barre latérale II [Pourquoi @kaz a raison]: bien sûr, il est évident, pour moi et d’autres cognoscenti, d’essayer simplement une séquence de commandes [tactiles] pour tromper le Makefile créé par configure de la réexécution de configure et des outils automatiques. Mais ce n'est pas le point de configurer; Le but de la configuration est d’assurer que autant d’utilisateurs que possible sur un maximum de systèmes différents puissent simplement faire [./configure && make] et passer à autre chose; la plupart des utilisateurs ne sont pas intéressés par "raser le yak", par exemple. déboguer des hypothèses erronées des développeurs d’autotools.
Encadré III: on pourrait soutenir que ./configure, maintenant que les outils automatiques ajoutent ces dépendances, est le mauvais outil de construction à utiliser avec les packages distribués par Github.
Sidebar IV: peut-être que les dépôts Github basés sur une configuration devraient mettre la commande tactile nécessaire dans leur readme, par exemple. https://github.com/drbitboy/Tycho2_SQLite_RTree .
Le problème n'est pas le package automake, c'est le référentiel
Sudo apt-get install automake
Installe la version aclocal-1.4, c'est pourquoi vous ne trouvez pas 1.5 (sous Ubuntu 14,15)
Utilisez ce script pour installer la dernière version https://github.com/gp187/nginx-builder/blob/master/fix/aclocal.sh
2017 - Haute Sierra
Il est très difficile de faire fonctionner autoconf 1.15 sur Mac. Nous avons engagé un expert pour le faire fonctionner. Tout a fonctionné à merveille.
Plus tard, il m'est arrivé de mettre à niveau un Mac vers High Sierra.
Le pipeline Docker a cessé de fonctionner!
Même si autoconf 1.15 est fonctionne bien sur le Mac.
Comment réparer,
Réponse courte, j'ai simplement détruit le dépôt local et vérifié à nouveau le dépôt.
Cette suggestion est notée dans le mix sur cette page QA et ailleurs.
Cela a ensuite bien fonctionné!
Il a probablement quelque chose à faire avec les fichiers aclocal.m4 et similaires. (Mais qui sait vraiment) J'ai massé sans fin ces fichiers ... mais rien.
Pour une raison inconnue, si vous ne faites que gratter votre rapport et le récupérer à nouveau: tout fonctionne!
J'ai essayé pendant des heures chaque combinaison de toucher/supprimer etc. les fichiers en question, mais non. Il suffit de consulter le repo à partir de zéro!