¿Cómo superar la advertencia "'aclocal-1.15' falta en su sistema"?

82

Estoy tratando de ejecutar un programa de c ++ en github. (disponible en el siguiente enlace https://github.com/mortehu/text-classifier )

Tengo una Mac y estoy tratando de ejecutarla en la terminal. Creo que he descargado autoconf y automake, pero no estoy seguro. Para ejecutar el programa, voy a la carpeta correcta en la terminal y luego ejecuto

./configure && make 

Pero me sale el error:

ADVERTENCIA: 'aclocal-1.15' falta en su sistema. Solo debería necesitarlo si modificó 'acinclude.m4' o 'configure.ac' o archivos m4 incluidos en 'configure.ac'. El programa 'aclocal' es parte del paquete GNU Automake: http://www.gnu.org/software/automake También requiere GNU Autoconf, GNU m4 y Perl para ejecutarse: http://www.gnu.org / software / autoconf http://www.gnu.org/software/m4/ http://www.perl.org/ make: *** [aclocal.m4] Error 127

Tengo xcode y g ++ y todas las cosas necesarias para ejecutar programas en c, pero como probablemente sea obvio, no tengo idea de lo que estoy haciendo.

¿Cuál es la forma más fácil y sencilla de ejecutar el programa en el enlace anterior? Me doy cuenta de que viene con un léame y un uso de ejemplo, pero no puedo hacer que funcione.

Liam Flynn
fuente
1
"todas las cosas necesarias para ejecutar programas c" - que necesita todas las cosas a compilar el programa, que en este caso incluye los paquetes automake, autoconf, m4, y perlautoconf, ya que el mensaje indica con toda claridad ... "Creo que he descargado y automake, pero no estoy seguro ". Estoy bastante seguro de que, al menos, no lo ha instalado correctamente. ;-)
DevSolar

Respuestas:

161

Antes de ejecutar, ./configureintente ejecutar autoreconf -f -i. El programa autoreconf ejecuta automáticamente autoheader, aclocal, automake, autopoint y libtoolize según sea necesario.

Editar para agregar: esto generalmente se debe a verificar el código de Git en lugar de extraerlo de un archivo .zipo .tar.gz. Para desencadenar reconstrucciones cuando los archivos cambian, Git no conserva las marcas de tiempo de los archivos, por lo que la configuresecuencia de comandos puede parecer obsoleta. Como han mencionado otros, hay formas de evitar esto si no tiene una versión suficientemente reciente de autoreconf.

Otra edición: este error también se puede producir al copiar la carpeta de origen extraída de un archivo con scp a otra máquina. Las marcas de tiempo se pueden actualizar, lo que sugiere que es necesaria una reconstrucción. Para evitar esto, copie el archivo y extráigalo en su lugar.

mortehu
fuente
¡Gracias Mortehu! Pero luego aparece el error: en el archivo incluido de base / columnfile.cc: 1: ./base/columnfile.h:8:10: error fatal: archivo 'kj / debug.h' no encontrado #include <kj / debug .h> ¿Me falta un archivo?
Liam Flynn
1
Sí, te falta libkj, que es parte del proyecto Cap'n Proto. También necesitará libsnappy.
mortehu
Bien, finalmente tengo todas las herramientas necesarias para configurar, hacer y hacer la instalación. Parece que todo funciona, pero ¿a dónde va el ejecutable? No estoy seguro de si esto es importante o relevante, pero recibo el siguiente mensaje (como parte de un mensaje mucho más grande) cuando hago la instalación: # No es un destino: instalar: # Línea de comandos de destino. # No se ha realizado la búsqueda de reglas implícitas. # Nunca se verificó el tiempo de modificación. # El archivo no ha sido actualizado. ¿Significa esto que no se crea ningún archivo de salida?
Liam Flynn
El programa debería terminar como tools/text-classifier/text-classifier. No sé por qué make installno funciona.
mortehu
esto podría suceder si ejecuta ./configure en su proyecto y luego actualiza el automakepaquete
Alec Istomin
52

A menudo, no es necesario ningún auto*herramientas y la solución más sencilla es simplemente ejecutar touch aclocal.m4 configureen la carpeta correspondiente (y también correr touchen Makefile.amy Makefile.insi es que existen). Esto actualizará la marca de tiempo aclocal.m4y le recordará al sistema que aclocal.m4está actualizado y no necesita ser reconstruido. Después de esto, probablemente sea mejor vaciar su builddirectorio y volver configurea ejecutarlo desde cero después de hacer esto. Me encuentro con este problema con regularidad. Para mí, la causa principal es que copio una biblioteca (por ejemplo, mpfrcódigo para gcc) de otra carpeta y las marcas de tiempo cambian.

Por supuesto, este truco no es válido si realmente necesita regenerar esos archivos, quizás porque los ha cambiado manualmente. Pero es de esperar que los desarrolladores del paquete distribuyan archivos actualizados.


Y, por supuesto, si desea instalar automakey amigos, utilice el administrador de paquetes adecuado para su distribución.


Instale un local que viene con automake:

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

Inténtalo de nuevo:

./configure && make 
emlai
fuente
Después de hacer eso, obtengo: configure.ac:25: error: se requiere la versión 2.69 o superior de Autoconf ... ADVERTENCIA: 'aclocal-1.15' probablemente sea demasiado antiguo. ... make: *** [aclocal.m4] Error 63
Liam Flynn
y luego de instalar autoconf v2.69 obtengo: libtool: Error de no coincidencia de la versión. Esto es libtool 2.4.2 Debian-2.4.2-1.11, pero libtool: la definición de este LT_INIT proviene de libtool 2.4.4. libtool: debe recrear aclocal.m4 con macros de libtool 2.4.2 Debian-2.4.2-1.11 libtool: y ejecutar autoconf nuevamente.
Liam Flynn
Asegúrese de haberlo hecho brew install libtool, luego ejecute aclocal, luego ejecute autoconf.
emlai
Actualicé libtool pero ahora obtengo: libtool: Error de no coincidencia de la versión. Esto es libtool 2.4.2 Debian-2.4.2-1.11, pero libtool: la definición de este LT_INIT proviene de libtool 2.4.6. libtool: debe recrear aclocal.m4 con macros de libtool 2.4.2 Debian-2.4.2-1.11 libtool: y ejecutar autoconf nuevamente.
Liam Flynn
Esto resuelve el problema. Pero no es necesario ya que requiere muchas otras cosas (privilegios de root, conexión de red, más espacio para software nuevo, etc.). La solución de Droopycon a continuación es (cercana a) una respuesta adecuada, ya que el mensaje de error dice claramente que "Solo debería necesitarlo si modificó 'acinclude.m4' o 'configure.ac' o los archivos m4 incluidos en 'configure.ac'". .
harihardik
10

Puede instalar la versión que necesita fácilmente:

Primero obtenga la fuente:

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

Desempaquetarlo:

$ tar -xzvf automake-1.15.tar.gz

Construya e instale:

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

Úselo:

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

aclocal (GNU automake) 1.15

Ahora, cuando se llama a un local, obtiene la versión correcta.

Frederick Ollinger
fuente
Esto instaló "un local" para mí. Lo instalé a través del instalador de interfaz de usuario de CygWin buscando "automake" y seleccionando la versión 11-1.
justdan23
8

Una respuesta genérica que puede o no aplicarse a este caso específico:

Como sugiere el mensaje de error, aclocal-1.15 solo debería ser necesario si modificó los archivos que se usaron para generar aclocal.m4

Si no modifica ninguno de esos archivos (incluido configure.ac), no debería necesitar tener aclocal-1.15.

En mi caso, el problema no fue que ninguno de esos archivos se haya modificado, sino que de alguna manera la marca de tiempo en configure.ac fue 6 minutos más tarde en comparación con aclocal.m4.

No he descubierto por qué, pero un clon limpio de mi repositorio de git me resolvió el problema. Tal vez algo relacionado con git y cómo creó archivos en primer lugar.

En lugar de volver a ejecutar autoconf y amigos, simplemente intentaría obtener un clon limpio y volver a intentarlo .

También es posible que alguien haya cometido un cambio en configure.ac pero no haya regenerado aclocal.m4, en cuyo caso tendrá que volver a ejecutar automake y friends.

Droopycom
fuente
1
Respuesta más apropiada. Recibí un error similar porque no extraje los archivos de origen del tar que proporciona squid. En su lugar, copié la carpeta ya extraída y mi orden de copia del archivo fue diferente, lo que causó un error. Simplemente volví a extraer del alquitrán directamente y comenzó a funcionar. Marcaría la solución de Droopycon como una respuesta adecuada, si tuviera la oportunidad.
harihardik
¡Brillante! Solía rsynccopiar los archivos ya extraídos de un servidor a otro (en lugar de copiar los archivos de origen comprimidos), sin conservar las marcas de tiempo. Cuando copié los archivos de origen y los extraje en la máquina de destino, el problema no se produjo. ¡Gracias!
Ben Johnson
De hecho, muy a menudo la respuesta es "Verifique el repositorio nuevo". ¡Respuesta y recompensa fantásticas!
Fattie
6

El objetivo de Autotools es proporcionar un lenguaje arcano basado en macros M4 que finalmente se compila en un script de shell llamado ./configure. Puede enviar este script de shell compilado con el código fuente y ese script debería hacer todo lo posible para detectar el entorno y preparar el programa para la construcción. Autotools solo debería ser requerido por alguien que quiera modificar las pruebas y actualizar ese script de shell.

Derrota el punto de Autotools si GNU This y GNU That deben estar instalados en el sistema para que funcione. Originalmente, se inventó para simplificar la migración de programas a varios sistemas Unix, de los que no se podía contar con nada. Incluso las construcciones utilizadas por el código de shell generado ./configuretuvieron que seleccionarse con mucho cuidado para asegurarse de que funcionarían en cada shell antiguo roto en casi todas partes.

El problema con el que se está encontrando se debe a algunos pasos de Makefile rotos inventados por personas que simplemente no entienden para qué es Autotools y el papel del ./configurescript final .

Como solución alternativa, puede ir al Makefile y realizar algunos cambios para solucionarlo. Como ejemplo, estoy construyendo el jefe de Git de GNU Awk y me encuentro con el mismo problema. Makefile.inSin embargo, apliqué este parche y puedo con éxito 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@

Básicamente, cambié las cosas para que el truecomando de shell inofensivo sustituya a todos los programas de Auto-stuff.

¡Los pasos de compilación reales para Gawk no necesitan las cosas automáticas! Solo está involucrado en algunas reglas que se invocan si algunas partes de Auto-stuff han cambiado y necesitan ser reprocesadas. Sin embargo, el Makefile está estructurado de tal manera que falla si las herramientas no están presentes.

Antes del parche anterior:

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

Después del parche:

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

Aquí vamos. Como puede ver, las CDPATH=líneas de comando allí son donde se invoca el Auto-stuff, donde se ven los truecomandos. Estos informan una terminación exitosa, por lo que simplemente se cae por esa basura para hacer la maldita construcción, que está perfectamente configurada.

Lo hice make gawkporque hay algunos subdirectorios que se crean y fallan; el truco debe repetirse para sus respectivos Makefiles.

Si te encuentras con este tipo de cosas con un tarball oficial y prístino del programa de sus desarrolladores, entonces quéjate. Simplemente debería descomprimirse ./configurey makesin tener que parchear nada o instalar ningún material de Automake o Autoconf.

Idealmente, un tirón de su cabeza Git también debería comportarse de esa manera.

Kaz
fuente
¿Por qué asume que los Makefiles están rotos? Como se señaló en la respuesta de emlai, el sistema de compilación reconoce que las dependencias de los archivos generados están desactualizadas (lo que puede ser solo el caso de las marcas de tiempo equivocadas que puede corregir touchcon ellos). Decir que las personas que crearon este sistema no entienden para qué fue creado (asegurándose de que compile correctamente con todas las dependencias, lo que incluye las auto*partes -si se cambian) y cambiando los Makefiles para que efectivamente no haga esto por completo más parece ... mal.
Simon Sobisch
@SimonSobisch ¿Tiene este problema y no puede utilizar la respuesta?
Kaz
Gracias por preguntar. No, no tengo este problema, pero al leer su publicación veo la línea de fondo "este error ocurre porque los Makefiles están rotos y no lo que deberían ser los Makefiles", mientras que los Makefiles están haciendo exactamente lo que deberían (reconstruyendo archivos que necesitan para reconstruir de acuerdo con las mismas reglas, un archivo de objeto se reconstruiría a partir de una fuente C). En la mayoría de los casos, el error se produce porque las personas utilizan paquetes que no son de distribución sin las herramientas necesarias o porque las marcas de tiempo de las fuentes están rotas "quejarse al autor".
Simon Sobisch
Yo no recomiendo cambiar a una herramienta true. Si realmente desea reparar las partes que están rotas "solo porque las marcas de tiempo", es mejor que se ejecuten make --touchcontra los objetivos defectuosos (si desea recopilarlas, ejecute make --keep-goingpara obtener una lista de las partes "rotas" de antemano).
Simon Sobisch
@SimonSobisch Grandes sugerencias; Suena como si tuviera el comienzo de una respuesta separada allí. En este caso, cambiar las herramientas a truese justifica racionalmente por el hecho de que esas herramientas son innecesarias para construir el programa, pero solo para reconstruir el configurescript, que ya está disponible en forma prediseñada. Tocar las marcas de tiempo para suprimir los intentos de ejecutar las herramientas logra el mismo efecto.
Kaz
4

Creo que el comando táctil es la respuesta correcta, por ejemplo, haz algo como

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

antes de [./configure && make].

Barra lateral I: De lo contrario, estoy de acuerdo con @kaz: agregar dependencias para aclocal.m4 y / o configure y / o Makefile.am y / o Makefile.in hace suposiciones sobre el sistema de destino que pueden no ser válidas. Específicamente, esos supuestos son

1) que todos los sistemas de destino tienen herramientas automáticas,

2) que todos los sistemas de destino tienen la misma versión de autotools (por ejemplo, automake.1.15 en este caso).

3) que si (1) o (2) no son verdaderas para cualquier usuario, el usuario está extrayendo el paquete de un formato TAR o ZIP producido por el mantenedor que mantiene las marcas de tiempo de los archivos relevantes, en cuyo caso todas las herramientas automáticas / configure /Makefile.am/Makefile.in las dependencias en el Makefile generado por configure se satisfarán antes de que se emita el comando make.

La segunda suposición falla en muchos sistemas Mac porque automake.1.14 es el "último" para OSX (al menos eso es lo que veo en MacPorts, y aparentemente lo mismo es cierto para brew).

La tercera suposición falla espectacularmente en un mundo con Github. Este fracaso es un ejemplo de una mentalidad de "todos piensan que son normativos"; específicamente, los mantenedores, que son la única clase de usuarios que deberían necesitar editar Makefile.am, ahora han puesto a todos en esa clase.

Quizás haya una opción en autowhatever que evita que estas dependencias se agreguen a Makefile.in y / o Makefile.

Barra lateral II [Por qué @kaz tiene razón]: por supuesto que es obvio, para mí y para otros entendidos, simplemente probar una secuencia de comandos [táctiles] para engañar al Makefile creado por configure para que vuelva a ejecutar configure y las herramientas automáticas. Pero ese no es el punto de configurar; el punto de la configuración es asegurar que tantos usuarios en tantos sistemas diferentes como sea posible puedan simplemente hacer [./configure && make] y seguir adelante; la mayoría de los usuarios no están interesados ​​en "depurar el yak", por ejemplo, depurar supuestos erróneos de los desarrolladores de autotools.

Barra lateral III: se podría argumentar que ./configure, ahora que autotools agrega estas dependencias, es la herramienta de compilación incorrecta para usar con paquetes distribuidos por Github.

Barra lateral IV: quizás los repositorios de Github basados ​​en la configuración deberían poner el comando táctil necesario en su archivo Léame, por ejemplo, https://github.com/drbitboy/Tycho2_SQLite_RTree .

Brian Carcich
fuente
4

2018, otra solución más ...

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

en algunos casos simplemente corriendo

$ autoreconf -f -i

y nada más .... resuelve el problema.

Haz eso en el directorio /pcre2-10.30.

Qué pesadilla.

(Esto por lo general no no resolver el problema en 2017, pero ahora por lo general no parecen resolver el problema - que fijan algo Además, parece que su Dockerfile debe ahora por lo general comienzan con "DE IBMCOM / Swift-ubuntu"; previamente había que dar. una determinada versión / dev-build para que funcione).

Fattie
fuente
0

2017 - High Sierra

Es muy difícil hacer que autoconf 1.15 funcione en Mac. Contratamos a un experto para que funcione. Todo funcionó a la perfección.

Más tarde se me ocurrió actualizar una Mac a High Sierra.

¡El oleoducto Docker dejó de funcionar!

A pesar de que autoconf 1.15 está trabajando muy bien en el Mac.

Como arreglar,

Respuesta corta, simplemente destruí el repositorio local y revisé el repositorio nuevamente.

Esta sugerencia se indica en la combinación de esta página de control de calidad y en otros lugares.

¡Entonces funcionó bien!

Es probable que tenga algo que ver con aclocal.m4 y archivos similares . (Pero quién sabe realmente). Masajeé esos archivos sin cesar ... pero nada.

Por alguna razón desconocida, si simplemente rasca su repositorio y vuelve a obtener el repositorio: ¡todo funciona!

Intenté durante horas cada combinación de tocar / eliminar, etc., etc., los archivos en cuestión, pero no. ¡Solo echa un vistazo al repositorio desde cero!

Fattie
fuente
Para que un repositorio de automake vuelva a su estado de pago, puede hacer: "hacer distclean".
Frederick Ollinger
Técnicamente, no es un comando de git. Es para limpiar un repositorio después de un ./configure. Entonces es parte de automake. Pero debería funcionar en cualquier repositorio de git que use automake.
Frederick Ollinger
gotchya, suena como un buen consejo.
Fattie
"Es realmente difícil hacer que autoconf 1.15 funcione en Mac. Contratamos a un Ultra-Experto para que funcione ..." - Eso nos dice cuán rota está esta cadena de herramientas. Y, lamentablemente, en más de 20 años, no se ha solucionado. No arreglarlo es lo que me molesta. ¿Para qué sirve dejarlo roto para que la gente no pueda usarlo?
jww