Utilisateur de autotools-généré archive obtient le message d'erreur: aclocal-1.13: command not found
Je suis la distribution d'un tarball avec l'installation des scripts générés par autoconf version 2.69. Fonctionne très bien sur beaucoup de machines différentes. Maintenant, un utilisateur, de travailler sur une nouvelle Arch Linux système, les rapports qui configure s'exécute correctement, mais make immédiatement se termine avec le message d'erreur suivant:
/home/user/project/build-aux/missing: line 81: aclocal-1.13: command not found
WARNING: 'aclocal-1.13' 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
Il n'y a pas de acinclude.m4 dans le répertoire du projet. L'utilisateur garantit qu'il n'a pas modifié aclocal.m4, configure.ac, les fichiers m4/, ou quoi que ce soit d'autre dans le projet.
Le message d'erreur n'a pas de sens pour moi: ce que je comprends, aclocal est exécutée quand je lance autoreconf -if; il génère un fichier aclocal.m4 qui fait partie de l'archive-je distribuer; il n'y a aucune raison pourquoi un utilisateur make commande doit demander aclocal.
L'utilisateur d'autres rapports qu'il peut résoudre le problème pour lui-même en exécutant aclocal. Cependant, ce n'est pas une solution propre: les emballeurs sont pas censé demander à leurs utilisateurs d'avoir autotools installé, non?
Pour être complet, je joins le plein configure.ac: est-il quelque chose de mal?
################################################################################
## FRIDA: fast reliable interactive data analysis ##
## configure.ac: used by 'autoreconf -i' to prepare for 'configure' ##
## (C) Joachim Wuttke, Sebastian Busch 2008- ##
## http://apps.jcns.fz-juelich.de/frida ##
################################################################################
################################################################################
## Generic initialization ##
################################################################################
AC_INIT([frida],[post-2.1.8c],[[email protected]])
# ^^^^^ delete "post-" for public releases
# project name must be "frida"; this determines the installation directories
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([foreign]) # don't insert GNU blala files
################################################################################
## Select compiler and preprocessors ##
################################################################################
AC_PROG_CXX
AC_LANG(C++)
AX_CXX_COMPILE_STDCXX_11 # provided in directory m4
AC_SUBST(AM_CXXFLAGS,"-g -pedantic -Wall -Wno-sign-compare -Wno-unused-result -Werror")
# for valgrind --leak-check=full frida, use -O0 -fno-inline
# source files that use -D settings must #include "../config.h"
AC_CONFIG_HEADERS([config.h]) # also needed to prevent endless -D option lists
AC_PROG_LEX # LEX,LEXLIB = "flex","-lfl" or "lex","-ll"
if test "$LEX" = :; then
AC_MSG_ERROR([Cannot find lex. Aborting.])
fi
AC_PROG_YACC # YACC = "bison -y" or "byacc" or "yacc"
if test "$YACC" = "yacc"; then
AC_MSG_ERROR([Cannot find yacc. Aborting.])
fi
## I put this one here only because qmake does: Make sure off_t is 64-bit in *nix, taken from http://www.google.com/search?q=cache:wlNJ8Qe4dBgJ:www.sfr-fresh.com/unix/privat/libfb-v0.18.4b-src.zip:a/src/rtlib/configure.ac+configure.ac+file+offset+bits&hl=de&ct=clnk&cd=5&gl=de&client=firefox-a
AC_DEFINE([_FILE_OFFSET_BITS],64,[File offset bits])
################################################################################
## Check for headers, defs needed at compile time ##
################################################################################
# Consistency check: is source code present?
AC_CONFIG_SRCDIR([src/frida2.cpp])
AC_CONFIG_SRCDIR([man/frida.pod])
# Checks for typedefs, structures, and compiler characteristics
AC_C_CONST
AC_C_INLINE
AC_TYPE_SIZE_T
AC_STRUCT_TM
AC_HEADER_STDBOOL
AC_HEADER_STDC
# Checks for standard includes
AC_FUNC_ALLOCA
AC_FUNC_MALLOC
AC_FUNC_REALLOC
AC_FUNC_MKTIME
AC_FUNC_STRFTIME
AC_CHECK_FUNCS([gettimeofday],,AC_MSG_ERROR([Cannot find gettimeofday.]))
AC_CHECK_FUNCS([memset], ,AC_MSG_ERROR([Cannot find memset.]))
AC_CHECK_FUNCS([mkfifo], ,AC_MSG_ERROR([Cannot find mkfifo.]))
AC_CHECK_FUNCS([strchr], ,AC_MSG_ERROR([Cannot find strchr.]))
AC_CHECK_HEADERS([fcntl.h], ,AC_MSG_ERROR([Cannot find fcntl.h.]))
AC_CHECK_HEADERS([math.h], ,AC_MSG_ERROR([Cannot find math.h.]))
# The following headers are needed for code produced by lexx and yacc
AC_CHECK_HEADERS([inttypes.h], ,AC_MSG_ERROR([Cannot find inttypes.h.]))
AC_CHECK_HEADERS([libintl.h], ,AC_MSG_ERROR([Cannot find libintl.h.]))
AC_CHECK_HEADERS([malloc.h], ,AC_MSG_ERROR([Cannot find malloc.h.]))
AC_CHECK_HEADERS([unistd.h], ,AC_MSG_ERROR([Cannot find unistd.h.]))
AC_CHECK_HEADERS([stddef.h], ,AC_MSG_ERROR([Cannot find stddef.h.]))
# Non-standard includes
AC_CHECK_HEADERS([gsl/gsl_rng.h gsl/gsl_randist.h gsl/gsl_math.h \
gsl/gsl_errno.h gsl/gsl_integration.h gsl/gsl_roots.h \
gsl/gsl_sf.h gsl/gsl_sf_debye.h],,
AC_MSG_ERROR([Cannot find required gsl headers.]))
# C includes of our own
AC_CHECK_HEADERS([kww.h],, AC_MSG_ERROR([Cannot find kww.h.]))
AC_CHECK_HEADERS([cerf.h],, AC_MSG_ERROR([Cannot find cerf.h.]))
# C++ includes of our own
AC_TRY_CPP([#include<boost/format.hpp>],,
AC_MSG_ERROR([Cannot find boost/format.hpp.]))
AC_TRY_CPP([#include<boost/shared_ptr.hpp>],,
AC_MSG_ERROR([Cannot find boost/shared_ptr.hpp.]))
AC_TRY_CPP([#include<trivia/file_ops.hpp>],,
AC_MSG_ERROR([Cannot find trivia/file_ops.hpp.]))
AC_TRY_CPP([#include<readplus/readln.hpp>],,
AC_MSG_ERROR([Cannot find readplus/readln.hpp.]))
AC_TRY_CPP([#include<yamlfreeze/yaml.hpp>],,
AC_MSG_ERROR([Cannot find yamlfreeze/yaml.hpp.]))
################################################################################
## Check for libraries, needed at link time ##
################################################################################
# From standard packages
AC_SEARCH_LIBS([cos], [m],, [AC_MSG_ERROR(libm not found or corrupted)])
AC_SEARCH_LIBS([cblas_dgemm], [gslcblas],,
[AC_MSG_ERROR(libgslcblas not found or out of sync)])
AC_SEARCH_LIBS([gsl_blas_dgemm], [gsl],,
[AC_MSG_ERROR(libgsl not found or out of sync)])
AC_SEARCH_LIBS([fftw_plan_r2r_1d], [fftw3],,
[AC_MSG_ERROR(libfftw not found or out of sync)])
AC_SEARCH_LIBS([rl_completion_matches], [readline],,
[AC_MSG_ERROR(libreadline not found or corrupted)])
# From our own C packages
AC_CHECK_LIB([lmfit], [lmmin], ,
[AC_MSG_ERROR(liblmfit not found or out of sync)])
AC_CHECK_LIB([kww], [kwwp], ,
[AC_MSG_ERROR(libkww not found or out of sync)])
AC_CHECK_LIB([cerf], [voigt], ,
[AC_MSG_ERROR(libcerf not found or out of sync)])
# From our own C++ packages (why checking for main? how else?)
AC_CHECK_LIB([trivia], [main], ,
[AC_MSG_ERROR(libtrivia not found or out of sync)])
AC_CHECK_LIB([readplus], [main],,
[AC_MSG_ERROR(library readplus not found)])
AC_CHECK_LIB([yamlfreeze], [main],,
[AC_MSG_ERROR(library yamlfreeze not found)])
################################################################################
## Check for facilities needed at run time ##
################################################################################
AC_CHECK_PROGS([GNUPLOT], [gnuplot], [:])
if test "$GNUPLOT" = :; then
AC_MSG_ERROR([Cannot find gnuplot. Aborting.])
fi
################################################################################
## make Makefiles ##
################################################################################
AC_CONFIG_FILES([Makefile src/Makefile man/Makefile share/Makefile])
AC_OUTPUT
Pourrait être le problème en raison de la présence de fichiers qui n'appartiennent pas à une archive? Ici le contenu de l'archive tgz, sauf pour les fichiers source d'eux-mêmes:
frida2.1.8c/aclocal.m4
frida2.1.8c/build-aux/
frida2.1.8c/build-aux/depcomp
frida2.1.8c/build-aux/ylwrap
frida2.1.8c/build-aux/ltmain.sh
frida2.1.8c/build-aux/missing
frida2.1.8c/build-aux/install-sh
frida2.1.8c/build-aux/config.guess
frida2.1.8c/build-aux/config.sub
frida2.1.8c/CHANGELOG
frida2.1.8c/config.h.in
frida2.1.8c/configure
frida2.1.8c/configure.ac
frida2.1.8c/COPYING
frida2.1.8c/INSTALL
frida2.1.8c/m4/
frida2.1.8c/m4/libtool.m4
frida2.1.8c/m4/m4_ax_boost_regex.m4
frida2.1.8c/m4/ltversion.m4
frida2.1.8c/m4/ltoptions.m4
frida2.1.8c/m4/lt~obsolete.m4
frida2.1.8c/m4/m4_ax_boost_base.m4
frida2.1.8c/m4/ax_cxx_compile_stdcxx_11.m4
frida2.1.8c/m4/ltsugar.m4
frida2.1.8c/Makefile.am
frida2.1.8c/Makefile.in
frida2.1.8c/man/
...
frida2.1.8c/share/
...
frida2.1.8c/src/
...
frida2.1.8c/test/
...
- Le problème semble lié avec d'obscurs "reconstruire les règles" (gnu.org/software/automake/manual/automake.html#Rebuilding), et avec le "manque" de script, avec solution de contournement possible sous la forme d'un obsolète macro
AM_MAINTAINER_MODE(gnu.org/software/automake/manual/html_node/...) - Avez-vous de créer l'archive avec
make distcheck? Qui attrape habituellement des erreurs comme ça.
Vous devez vous connecter pour publier un commentaire.
Ok, donc j'ai eu exactement ce problème aussi, c'est me rend fou. Le problème semble être que j'ai été faire un svn export du code source pour faire ma src archive.
Maintenant c'est bien, mais corrigez-moi si je me trompe, mais je pense que svn s'engage uniquement les fichiers qui ont été modifiés, de ne pas toucher. Cela signifie que lorsque vous venez de vérifier les fichiers à l'aide d'un svn exporter les fichiers peuvent être chronologiquement dans le mauvais ordre, même si les fichiers comme:
configurer.ca aclocal.m4 configurer Makefile.suis Makefile.dans
Avons tous été touchés récemment, svn de cachets de date ne sera pas mis à jour, donc si vous venez de publier le code source de package, les dates sont dans le mauvais ordre et de l'étape de configuration échoue (pas trop évidemment).
Après avoir fait svn export, souvenez-vous toujours de toucher à ces fichiers avant de la src est regroupé dans un tar.gz en utilisant les commandes:
Sinon, l'utilisateur sera obligé de toucher les fichiers eux-mêmes:
ou exécuter:
qui permettra de retoucher ces fichiers, au lieu de:
Qui est beaucoup plus facile pour l'utilisateur final.
m4/*et, éventuellement,config.h.in(si vous utilisezautoheader) doit être ajoutée à la liste destouched des fichiers.AM_INIT_AUTOMAKEn'est pas obsolète, mais je ne vois pas comment c'est lié à ce problème de toute façon...git. Merci pour l'aperçu ici.faire -d a donné un indice:
En quelque sorte les horodateurs n'ai pas compris, qui ont activé la "reconstruire les règles". Depuis ce qui se passe encore et encore, j'ai finalement opté pour
dans
configure.ac. J'ai lu que l'auteur de cette macro suis convaincu que c'était une mauvaise idée, mais pour moi, il semble bien fonctionner. Séparation claire des tâches: Le responsable a pour exécuterautoreconfchaque fois queconfigure.acou unMakefile.ama changé. L'utilisateur final doit ni besoin ni d'être induites à se régénérerconfigure.configure.acplus récente queaclocal.m4? Dans l'archive vous aviez pour elle, c'était certainement anciens. Vous doit distributionconfigure.ac, BTW.De course
autoreconf -vfidans le répertoire où le fichier de configuration est situé (dans mon cas: /source/evtest/evtest-1.31/) a travaillé pour moi le manque d'aclocal-1.13 en raison d'un trop nouvelle version (aclocal-1.14).
À résoudre, exécutez aclocal, puis automake dans le répertoire de niveau supérieur avant d'appeler le faire. Cela va reconstruire les fichiers "makefile" à l'aide de la version installée de autotools.
Avant le construire, le faire
Cela ne les aidera pas dans tous les cas, pour la construction de logiciel, mais il aide bien sûr dans Jenkins emplois et Rpm scripts de compilation.
Contexte: dans le dernier
autoreconfexécuter l'outil a découvert qu'un add-on de macro a été mis à jour, il copié ax_cxx_compile_stdcxx_11.m4 à partir de /usr/share/aclocal/aux ./m4. Il n'a également reconstruire le ./aclocal.m4, cependant, que vous n'avez pas introduit un véritable changement. Donc sur le prochain commit seulement ./m4/xxmacro.m4 macro est envoyé vers le dépôt central, et sur la prochaine versioncontrol-mise à jour dans un endroit différent, vous vous retrouvez avec une version plus récente (mise à jour) .m4/xxmacro.m4 que ./aclocal.m4 (pas à jour). Cela peut même se faire emballer dans une archive. Comme Joachim Wuttke a souligné ci-dessus, les différences dans les horodatages des déclencheurs de la reconstruction. Et vous pouvez éviter les différents horodateurs en touchant aclocal.m4 qui va à l'encontre de la mauvaise hypothèses de automake.J'ai eu à recompiler version exacte pour résoudre le problème. Je c'était de ruiner mon personnalisée nginx compilation. Vous pouvez voir le correctif ici
ou voici le script lui-même. 1.5 exactement ce qui était très important pour OpenSSL et Lua compilation
J'ai été confrontée au même problème
Pour moi, ce problème était dû à un même fichier source, j'ai été en utilisant le même fichier source à installer sur un autre serveur.
Une fois, j'ai supprimé l'ancien et extrait le fichier tar encore une fois sur un autre serveur, la question ai résolu.
J'ai pu installer Htop de commande de ligne de commande.
PFB pour votre refrence....