Wie kann man die Warnung "'aclocal-1.15' fehlt auf Ihrem System" überwinden?

82

Ich versuche ein C ++ - Programm auf Github auszuführen. (verfügbar unter folgendem Link https://github.com/mortehu/text-classifier )

Ich habe einen Mac und versuche ihn im Terminal auszuführen. Ich glaube, ich habe autoconf und automake heruntergeladen, bin mir aber nicht sicher. Um das Programm auszuführen, gehe ich in den richtigen Ordner im Terminal und laufe dann

./configure && make 

Aber ich bekomme den Fehler:

WARNUNG: 'aclocal-1.15' fehlt auf Ihrem System. Sie sollten es nur benötigen, wenn Sie die in 'configure.ac' enthaltenen Dateien 'acinclude.m4' oder 'configure.ac' oder m4 geändert haben. Das 'aclocal'-Programm ist Teil des GNU Automake-Pakets: http://www.gnu.org/software/automake Zum Ausführen sind außerdem GNU Autoconf, GNU m4 und Perl erforderlich: http://www.gnu.org / software / autoconf http://www.gnu.org/software/m4/ http://www.perl.org/ make: *** [aclocal.m4] Fehler 127

Ich habe xcode und g ++ und alle Dinge, die zum Ausführen von c-Programmen erforderlich sind, aber wie es wahrscheinlich offensichtlich ist, habe ich keine Ahnung, was ich tue.

Was ist der einfachste und einfachste Weg, um das Programm über den obigen Link auszuführen? Mir ist klar, dass es eine Readme-Datei und eine Beispielverwendung gibt, aber ich kann das nicht zum Laufen bringen.

Liam Flynn
quelle
1
„All die Dinge erforderlich c - Programme ausführen“ - Sie alle Dinge müssen kompilieren das Programm, das in diesem Fall die Pakete enthält automake, autoconf, m4, und perl, wie die Botschaft ganz klar sagt ... „Ich denke , ich habe autoconf und automake, bin mir aber nicht sicher "- Ich bin mir ziemlich sicher, dass Sie es zumindest nicht richtig installiert haben . ;-)
DevSolar

Antworten:

160

./configureVersuchen Sie vor dem Laufen zu laufen autoreconf -f -i. Das Autoreconf-Programm führt nach Bedarf automatisch Autoheader, Aclocal, Automake, Autopoint und Libtoolize aus.

Zum Hinzufügen bearbeiten: Dies wird normalerweise durch das Auschecken von Code aus Git verursacht, anstatt ihn aus einem .zipoder einem .tar.gzArchiv zu extrahieren . Um beim Erstellen von Dateien Neuerstellungen auszulösen, behält Git die Zeitstempel der Dateien nicht bei, sodass das configureSkript möglicherweise veraltet zu sein scheint. Wie andere bereits erwähnt haben, gibt es Möglichkeiten, dies zu umgehen, wenn Sie nicht über eine ausreichend aktuelle Version von verfügen autoreconf.

Eine weitere Änderung: Dieser Fehler kann auch durch Kopieren des aus einem Archiv mit scp extrahierten Quellordners auf einen anderen Computer verursacht werden. Die Zeitstempel können aktualisiert werden, was darauf hindeutet, dass eine Neuerstellung erforderlich ist. Um dies zu vermeiden, kopieren Sie das Archiv und extrahieren Sie es an Ort und Stelle.

mortehu
quelle
Danke Mortehu! Aber dann erhalte ich den Fehler: In Datei aus base / columnfile.cc: 1: ./base/columnfile.h:8:10: Schwerwiegender Fehler: 'kj / debug.h' Datei nicht gefunden #include <kj / debug .h> Vermisse ich eine Datei?
Liam Flynn
1
Ja, Ihnen fehlt libkj, das Teil des Cap'n Proto-Projekts ist. Sie benötigen auch libsnappy.
Mortehu
Okay, ich habe endlich alle notwendigen Tools zum Konfigurieren, Erstellen und Installieren. Es scheint alles zu funktionieren, aber wohin geht die ausführbare Datei? Ich bin mir nicht sicher, ob dies wichtig oder relevant ist, aber ich erhalte die folgende Meldung (als Teil einer viel größeren Meldung), wenn ich installiere: # Kein Ziel: install: # Befehlszeilenziel. # Die implizite Regelsuche wurde nicht durchgeführt. # Änderungszeit nie überprüft. # Datei wurde nicht aktualisiert. Bedeutet dies, dass keine Ausgabedatei erstellt wird?
Liam Flynn
Das Programm sollte als enden tools/text-classifier/text-classifier. Ich weiß nicht warum make installnicht funktioniert.
Mortehu
Dies kann passieren, wenn Sie ./configure in Ihrem Projekt ausführen und dann das automakePaket aktualisieren
Alec Istomin
52

Oft brauchen Sie keine auto*Werkzeuge und die einfachste Lösung ist, einfach laufen touch aclocal.m4 configureim entsprechenden Ordner (und auch laufen touchauf Makefile.amund Makefile.inwenn sie vorhanden sind ). Dadurch wird der Zeitstempel des aclocal.m4Systems aktualisiert und daran erinnert, dass aclocal.m4es auf dem neuesten Stand ist und nicht neu erstellt werden muss. Danach ist es wahrscheinlich am besten, das buildVerzeichnis zu leeren und danach erneut zu starten configure. Ich stoße regelmäßig auf dieses Problem. Für mich ist die Hauptursache, dass ich eine Bibliothek (z. B. mpfrCode für gcc) aus einem anderen Ordner kopiere und die Zeitstempel sich ändern.

Natürlich ist dieser Trick nicht gültig, wenn Sie diese Dateien wirklich neu generieren müssen, möglicherweise weil Sie sie manuell geändert haben. Hoffentlich verteilen die Entwickler des Pakets aktuelle Dateien.


Und wenn Sie automakeund Freunde installieren möchten, verwenden Sie natürlich den entsprechenden Paket-Manager für Ihre Distribution.


Installieren Sie aclocal, das mit automake geliefert wird:

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

Versuchen Sie es nochmal:

./configure && make 
Emlai
quelle
Danach erhalte ich: configure.ac:25: Fehler: Autoconf Version 2.69 oder höher ist erforderlich ... WARNUNG: 'aclocal-1.15' ist wahrscheinlich zu alt. ... machen: *** [aclocal.m4] Fehler 63
Liam Flynn
und dann nach der Installation von autoconf v2.69 erhalte ich: libtool: Versionsfehler. Dies ist libtool 2.4.2 Debian-2.4.2-1.11, aber die libtool: Definition dieses LT_INIT stammt aus libtool 2.4.4. libtool: Sie sollten aclocal.m4 mit Makros aus libtool 2.4.2 Debian-2.4.2-1.11 neu erstellen. libtool: und autoconf erneut ausführen.
Liam Flynn
Stellen Sie sicher, dass Sie fertig sind brew install libtool, und führen Sie aclocaldann aus autoconf.
Emlai
Ich habe libtool aktualisiert, aber jetzt erhalte ich: libtool: Versionsfehler. Dies ist libtool 2.4.2 Debian-2.4.2-1.11, aber die libtool: Definition dieses LT_INIT stammt aus libtool 2.4.6. libtool: Sie sollten aclocal.m4 mit Makros aus libtool 2.4.2 Debian-2.4.2-1.11 neu erstellen. libtool: und autoconf erneut ausführen.
Liam Flynn
Dies löst das Problem. Dies ist jedoch nicht erforderlich, da viele andere Dinge erforderlich sind (Root-Rechte, Netzwerkverbindung, mehr Speicherplatz für neue Software usw.). Die unten stehende Lösung von Droopycon ist (fast) eine richtige Antwort, da in der Fehlermeldung eindeutig angegeben ist: "Sie sollten sie nur benötigen, wenn Sie die in 'configure.ac' enthaltenen Dateien 'acinclude.m4' oder 'configure.ac' oder m4 geändert haben." .
Harihardik
10

Sie können die benötigte Version einfach installieren:

Zuerst Quelle erhalten:

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

Pack es aus:

$ tar -xzvf automake-1.15.tar.gz

Erstellen und installieren:

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

Benutze es:

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

aclocal (GNU automake) 1.15

Wenn jetzt aclocal aufgerufen wird, erhalten Sie die richtige Version.

Frederick Ollinger
quelle
Dies installierte "aclocal" für mich. Ich habe es über CygWins UI Installer installiert, indem ich nach "automake" gesucht und Version 11-1 ausgewählt habe.
Justdan23
8

Eine generische Antwort, die für diesen speziellen Fall gelten kann oder nicht:

Wie die Fehlermeldung andeutet, sollte aclocal-1.15 nur erforderlich sein, wenn Sie Dateien geändert haben, die zum Generieren von aclocal.m4 verwendet wurden

Wenn Sie keine dieser Dateien (einschließlich configure.ac) ändern, sollten Sie aclocal-1.15 nicht benötigen.

In meinem Fall bestand das Problem nicht darin, dass eine dieser Dateien geändert wurde, aber irgendwie war der Zeitstempel auf configure.ac 6 Minuten später im Vergleich zu aclocal.m4.

Ich habe nicht herausgefunden warum, aber ein sauberer Klon meines Git Repo hat das Problem für mich gelöst. Vielleicht etwas, das mit Git zu tun hat und wie es überhaupt Dateien erstellt hat.

Anstatt Autoconf und Freunde erneut auszuführen, würde ich einfach versuchen, einen sauberen Klon zu erhalten und es erneut zu versuchen .

Es ist auch möglich, dass jemand eine Änderung an configure.ac vorgenommen hat, aber aclocal.m4 nicht neu generiert hat. In diesem Fall müssen Sie tatsächlich automake und friends erneut ausführen.

Droopycom
quelle
1
Passendere Antwort. Ich habe den ähnlichen Fehler erhalten, weil ich keine Quelldateien aus tar extrahiert habe, das von squid bereitgestellt wird. Stattdessen habe ich den bereits extrahierten Ordner kopiert und meine Reihenfolge beim Kopieren der Datei war anders, was zu Fehlern führte. Ich habe einfach direkt aus Teer extrahiert und es fing an zu funktionieren. Ich würde die Lösung von Droopycon als eine richtige Antwort markieren, wenn ich eine Chance hätte.
Harihardik
Brillant! Ich hatte rsyncdie bereits extrahierten Dateien von einem Server auf einen anderen kopiert (anstatt die komprimierten Quellarchive zu kopieren), ohne die Zeitstempel beizubehalten. Als ich stattdessen die Quellarchive kopierte und auf dem Zielcomputer extrahierte, trat das Problem nicht auf. Vielen Dank!
Ben Johnson
In der Tat lautet die Antwort sehr oft "Checkout the repo fresh". Fantastische Antwort und Kopfgeld!
Fattie
6

Der Sinn von Autotools besteht darin, eine arkane M4-Makro-basierte Sprache bereitzustellen, die letztendlich zu einem Shell-Skript namens kompiliert wird ./configure. Sie können dieses kompilierte Shell-Skript mit dem Quellcode versenden. Dieses Skript sollte alles tun, um die Umgebung zu erkennen und das Programm für die Erstellung vorzubereiten. Autotools sollten nur von jemandem benötigt werden, der die Tests optimieren und das Shell-Skript aktualisieren möchte.

Es besiegt den Punkt von Autotools, wenn GNU This und GNU That auf dem System installiert sein müssen, damit es funktioniert. Ursprünglich wurde es erfunden, um die Portierung von Programmen auf verschiedene Unix-Systeme zu vereinfachen, auf die man sich nicht verlassen konnte. Sogar die Konstrukte, die vom generierten Shell-Code in verwendet wurden, ./configuremussten sehr sorgfältig ausgewählt werden, um sicherzustellen, dass sie auf jeder kaputten alten Shell fast überall funktionieren.

Das Problem, auf das Sie stoßen, ist auf einige fehlerhafte Makefile-Schritte zurückzuführen, die von Leuten erfunden wurden, die einfach nicht verstehen, wofür Autotools gedacht sind und welche Rolle das endgültige ./configureSkript spielt.

Um dieses Problem zu umgehen, können Sie in das Makefile gehen und einige Änderungen vornehmen, um dies aus dem Weg zu räumen. Als Beispiel baue ich den Git-Kopf von GNU Awk und stoße auf dasselbe Problem. Ich habe diesen Patch Makefile.injedoch angewendet und kann erfolgreich 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@

Grundsätzlich habe ich die Dinge so geändert, dass der harmlose trueShell-Befehl alle Auto-Stuff-Programme ersetzt.

Die eigentlichen Build-Schritte für Gawk benötigen kein Auto-Zeug! Es ist nur an einigen Regeln beteiligt, die aufgerufen werden, wenn Teile des Auto-Materials geändert wurden und erneut verarbeitet werden müssen. Das Makefile ist jedoch so strukturiert, dass es fehlschlägt, wenn die Tools nicht vorhanden sind.

Vor dem obigen Patch:

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

Nach dem 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.
[...]

Na, bitte. Wie Sie sehen können, CDPATH=befinden sich in den Befehlszeilen dort, wo das Auto-Zeug aufgerufen wurde, die trueBefehle. Diese melden eine erfolgreiche Beendigung, und so fällt es einfach durch diesen Müll, um den verdammten Build auszuführen, der perfekt konfiguriert ist.

Ich habe make gawkes getan, weil einige Unterverzeichnisse erstellt werden, die fehlschlagen. Der Trick muss für die jeweiligen Makefiles wiederholt werden.

Wenn Sie auf solche Dinge mit einem makellosen, offiziellen Tarball des Programms von seinen Entwicklern stoßen, dann beschweren Sie sich. Es sollte nur auspacken, ./configureund makeohne dass Sie etwas zu flicken oder irgendwelche Automake- oder Autoconf Materialien zu installieren.

Idealerweise sollte sich auch ein Ziehen des Git-Kopfes so verhalten.

Kaz
quelle
Warum nehmen Sie an, dass die Makefiles kaputt sind? Wie in Emlais Antwort ausgeführt, erkennt das Build-System, dass die Abhängigkeiten für die generierten Dateien veraltet sind (was möglicherweise nur bei vermasselten Zeitstempeln der Fall ist, die Sie beheben können, indem touchSie sie ändern). Zu sagen, dass die Personen, die dieses System erstellt haben, nicht verstehen, wofür es erstellt wurde (um sicherzustellen, dass Sie mit allen Abhängigkeiten korrekt erstellen - einschließlich der auto*Teile, wenn sie geändert werden) und die Makefiles zu ändern, um dies effektiv nicht vollständig zu tun mehr scheint ... falsch.
Simon Sobisch
@SimonSobisch Haben Sie dieses Problem und können die Antwort nicht verwenden?
Kaz
Danke für die Nachfrage. Nein, ich habe dieses Problem nicht, aber beim Lesen Ihres Beitrags sehe ich unter dem Strich "Dieser Fehler tritt auf, weil die Makefiles beschädigt sind und nicht das, was Makefiles sein sollten" - während die Makefiles genau das tun, was sie sollten (Dateien neu erstellen, die benötigt werden Um nach denselben Regeln neu erstellt zu werden, wird eine Objektdatei aus einer C-Quelle neu erstellt. In den meisten Fällen tritt der Fehler auf, weil Benutzer nicht-dist-Pakete ohne die erforderlichen Tools verwenden oder die Zeitstempel aus den Quellen "beim Autor beschweren" fehlerhaft sind.
Simon Sobisch
Ich würde niemals empfehlen, ein Werkzeug zu ändern true. Wenn Sie die defekten Teile wirklich reparieren möchten, "nur weil die Zeitstempel" besser make --touchgegen die fehlerhaften Ziele laufen (wenn Sie sie sammeln möchten, führen Sie sie aus make --keep-going, um vorher eine Liste der "defekten" Teile zu erhalten).
Simon Sobisch
@ SimonSobisch Tolle Vorschläge; klingt so, als hätten Sie dort die Anfänge einer separaten Antwort. In diesem Fall ist das Ändern der Tools in truerational gerechtfertigt, da diese Tools nicht zum Erstellen des Programms erforderlich sind, sondern nur zum erneuten Erstellen des configureSkripts, das bereits in vorgefertigter Form verfügbar ist. Durch Berühren der Zeitstempel, um Versuche zu unterdrücken, die Werkzeuge auszuführen, wird der gleiche Effekt erzielt.
Kaz
4

Ich denke, der Touch-Befehl ist die richtige Antwort, zB etwas wie

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

vor [./configure && make].

Seitenleiste I: Ansonsten stimme ich @kaz zu: Durch Hinzufügen von Abhängigkeiten für aclocal.m4 und / oder configure und / oder Makefile.am und / oder Makefile.in werden Annahmen über das Zielsystem getroffen, die möglicherweise ungültig sind. Insbesondere sind diese Annahmen

1) dass alle Zielsysteme Autotools haben,

2) dass alle Zielsysteme dieselbe Version von Autotools haben (z. B. automake.1.15 in diesem Fall).

3) Wenn entweder (1) oder (2) für keinen Benutzer zutreffen, extrahiert der Benutzer das Paket aus einem vom Betreuer erstellten TAR- oder ZIP-Format, das die Zeitstempel der relevanten Dateien verwaltet. In diesem Fall werden alle Autotools / Konfigurationen durchgeführt /Makefile.am/Makefile.in Abhängigkeiten im konfigurierten Makefile werden erfüllt, bevor der Befehl make ausgegeben wird.

Die zweite Annahme schlägt auf vielen Mac-Systemen fehl, da automake.1.14 das "neueste" für OSX ist (zumindest sehe ich das in MacPorts, und anscheinend gilt das Gleiche für das Brauen).

Die dritte Annahme scheitert spektakulär in einer Welt mit Github. Dieses Versagen ist ein Beispiel für eine Denkweise, bei der "jeder denkt, er sei normativ". Insbesondere die Betreuer, die die einzige Benutzerklasse sind, die Makefile.am bearbeiten muss, haben jetzt alle in diese Klasse eingeordnet .

Möglicherweise gibt es in autowhatever eine Option, die verhindert, dass diese Abhängigkeiten zu Makefile.in und / oder Makefile hinzugefügt werden.

Sidebar II [Warum @kaz richtig ist]: Natürlich ist es für mich und andere Cognoscenti offensichtlich, einfach eine Folge von [touch] -Befehlen auszuprobieren, um das von configure erstellte Makefile davon abzuhalten, configure und die Autotools erneut auszuführen. Aber das ist nicht der Punkt der Konfiguration; Der Zweck der Konfiguration besteht darin, sicherzustellen, dass so viele Benutzer auf so vielen verschiedenen Systemen wie möglich einfach [./configure && make] ausführen und fortfahren können. Die meisten Benutzer sind nicht daran interessiert, das Yak zu rasieren, z. B. fehlerhafte Annahmen der Autotool-Entwickler zu debuggen.

Seitenleiste III: Es könnte argumentiert werden, dass ./configure, nachdem Autotools diese Abhängigkeiten hinzugefügt hat, das falsche Build-Tool für Github-verteilte Pakete ist.

Seitenleiste IV: Möglicherweise sollten konfigurationsbasierte Github-Repos den erforderlichen Touch-Befehl in ihre Readme-Datei aufnehmen, z . B. https://github.com/drbitboy/Tycho2_SQLite_RTree .

Brian Carcich
quelle
4

2018, noch eine Lösung ...

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

in einigen Fällen einfach laufen

$ autoreconf -f -i

und sonst nichts .... löst das Problem.

Das machen Sie im Verzeichnis /pcre2-10.30.

Was ein Alptraum.

(Diese Regel hat nicht das Problem lösen , im Jahr 2017, aber jetzt in der Regel nicht scheint , das Problem zu lösen - sie etwas befestigt Auch scheint es , Ihre Dockerfile sollten jetzt in der Regel beginnen mit „FROM IBMCOM / swift-ubuntu“, vorher mußte man geben. eine bestimmte Version / dev-build, damit es funktioniert.)

Fattie
quelle
0

2017 - Hohe Sierra

Es ist wirklich schwierig, autoconf 1.15 auf einem Mac zum Laufen zu bringen. Wir haben einen Experten beauftragt, damit es funktioniert. Alles hat wunderbar funktioniert.

Später habe ich zufällig einen Mac auf High Sierra aktualisiert.

Die Docker-Pipeline funktioniert nicht mehr!

Auch wenn autoconf 1.15 ist gut funktioniert auf dem Mac.

Wie repariert man,

Kurze Antwort, ich habe einfach das lokale Repo verworfen und das Repo erneut ausgecheckt.

Dieser Vorschlag ist in der Mischung auf dieser QS-Seite und an anderer Stelle vermerkt.

Es hat dann gut funktioniert!

Es hat wahrscheinlich etwas mit aclocal.m4 und ähnlichen Dateien zu tun . (Aber wer weiß das wirklich). Ich habe diese Dateien endlos massiert ... aber nichts.

Aus irgendeinem unbekannten Grund, wenn Sie nur Ihr Repo kratzen und das Repo wieder erhalten: alles funktioniert!

Ich habe stundenlang jede Kombination aus Berühren / Löschen usw. usw. der fraglichen Dateien versucht, aber nein. Schauen Sie sich das Repo einfach von Grund auf an!

Fattie
quelle
Um ein Automake-Repo wieder in den Checkout-Status zu versetzen, können Sie Folgendes tun: "make distclean".
Frederick Ollinger
Technisch gesehen ist es kein Git-Befehl. Es geht darum, ein Repository nach einer ./configure zu bereinigen. Es ist also Teil von automake. Es sollte jedoch auf jedem Git-Repository funktionieren, das Automake verwendet.
Frederick Ollinger
gotchya, das klingt nach einem tollen Tipp.
Fattie
"Es ist wirklich schwierig, autoconf 1.15 auf einem Mac zum Laufen zu bringen. Wir haben einen Ultra-Experten beauftragt, damit es funktioniert ..." - Das zeigt uns, wie kaputt diese Toolchain ist. Und leider wurde es in mehr als 20 Jahren nicht behoben. Es nicht zu reparieren, ist die Sache, von der ich eine Ausnahme mache. Welchen Zweck hat es, es kaputt zu lassen, damit die Leute es nicht benutzen können?
Jww