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.

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.

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 

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.

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.

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.

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 .

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

El problema no es el automakepaquete, es el repositorio

sudo apt-get install automake

Instala la versión aclocal-1.4, por eso no puede encontrar 1.5(en Ubuntu 14,15)

Utilice este script para instalar la última https://github.com/gp187/nginx-builder/blob/master/fix/aclocal.sh

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!