Autotools Fehlerlog auswerten

[Wulf D. (holler)]

Kennst sich jemand im Autotools Build-System aus?

Ich versuche gerade ein älteres (~2006) open source Programm auf einem 
aktuellen Ubuntu zu bauen. Es werden Autotools verwendet.

Habe zwar Grundkenntnisse in makefile und bash, aber von der M4 
Macrosprache noch nie gehört.

Der Build ist ziemlich komplex, zuerst werden für mich nicht benötigte 
Libs gebaut (QT, AAC, ...), dann der eigentliche Code. Es geht um eine 
alte Version 1.12 des DRM Dream Decoders. Die bietet einen 
Simulationsmode, beispielsweise ohne das QT User Interface und die 
Quellendecoder AAC. Das sollte sich über Parameter ins configure steuern 
(abschalten mit --enable-simulation) lassen.

Zum eigentlichen Punkt: ausgehend vom Makefile.am und configure.in bauen 
die Autotools das sehr längliche configure. Jenes sollte dann mit 
übergebenen Parametern das finale makefile erzeugen. Tut es aber nicht. 
Meine Hoffnung ist, dass mir config.log Hinweise auf Fehler gibt. Eine 
Suche nach "error" liefert viele Treffer, z.B.

configure:4332: gcc -V >&5
gcc: error: unrecognized command-line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:4343: $? = 1
configure:4332: gcc -qversion >&5
gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:4343: $? = 1
configure:4332: gcc -version >&5
gcc: error: unrecognized command-line option '-version'
gcc: fatal error: no input files
compilation terminated.

Ich frage mich, ist das von Relevanz oder werden da einfach mehrere 
Abfragen nach der Compilerversion nur durchiteriert?
Die Sequenz taucht mehrfach im Log auf.

Weitere Frage: kann man aus den im Log angegebenen Nummern, hier als 
Beispiel 18699, auf die Fehler auslösende Zeile im configure schließen?
Sehe da irgendwie keinen Zusammenhang. Hier eine Meldung im Log:

configure:18699: g++ -o conftest -g -O2 -I/home/wulf/Dokumente/HF/dream/drm/libs -I/home/wulf/Dokumente/HF/dream/drm/linux/moc   conftest.cpp -ldfftw  -lrt -lz  -L/home/wulf/Dokumente/HF/dream/drm/libs >&5
/usr/bin/ld: cannot find -ldfftw: No such file or directory
collect2: error: ld returned 1 exit status
configure:18699: $? = 1
configure: failed program was:
| /* confdefs.h */

Und hier die Zeile 18699 im configure:

  if ac_fn_cxx_try_link "$LINENO"

[Harald K. (kirnbichler)]

> /usr/bin/ld: cannot find -ldfftw: No such file or directory

Gibt es denn irgendwo auf Deinem Rechner eine libdfftw.a oder .so?

[Wulf D. (holler)]

Nein, die gibt es nicht. An sich genommen, sind die Fehlermeldung alle 
plausibel. Aber wo kommen die Befehle her, sind die relevant?

"gcc -version >&5" führt auch zu einem Fehler, um mal ein Beispiel von 
weiter oben zu nehmen. Wenn ich das in die shell tippe, kommt exakt der 
gleiche Fehler wie im Log. Aber wo kommt das her?

In den Eingangsdateien wie configure.in und Makefile.am steht nichts 
davon. Das haben sich die Autotools irgend wo her generiert, aber woher? 
Ist es relevant?

[Oliver S. (oliverso)]

Wulf D. schrieb:
> Aber wo kommt das her?

gcc kennt die Optionen -v und —version. Kommen die denn da auch irgendwo 
vor?

Oliver

[Harald K. (kirnbichler)]

Oliver S. schrieb:
> gcc kennt die Optionen -v und —version. Kommen die denn da auch irgendwo
> vor?

Die Reaktion von Wulfs gcc auf -version sieht man hier:

Wulf D. schrieb:
> configure:4332: gcc -version >&5
> gcc: error: unrecognized command-line option '-version'

[Norbert (der_norbert)]

Wulf D. schrieb:
> "gcc -version >&5" führt auch zu einem Fehler, um mal ein Beispiel von
> weiter oben zu nehmen. Wenn ich das in die shell tippe, kommt exakt der
> gleiche Fehler wie im Log. Aber wo kommt das her?

gcc -v

gcc --version

erzeugen zwei völlig unterschiedliche Ausgaben.
Die Umleitung

>&5

 funktioniert nur, wenn auch irgend jemand auf diesem Descriptor 
lauscht. In die Bash eingetippt ist das tendentiell eher 
unwahrscheinlich.
Vermutlich wird die Ausgabe von einem weiteren Werkzeug auf ›5‹ entgegen 
genommen und nach bestimmten Informationen durchsucht.

[Oliver S. (oliverso)]

Harald K. schrieb:
> Oliver S. schrieb:
>> gcc kennt die Optionen -v und —version. Kommen die denn da auch irgendwo
>> vor?
>
> Die Reaktion von Wulfs gcc auf -version sieht man hier:
>
> Wulf D. schrieb:
>> configure:4332: gcc -version >&5
>> gcc: error: unrecognized command-line option '-version'

Finde den Unterschied…
Ist hier im Forum allerdings schwer zu erkennen.
Die Langversionen der Optionen haben zwei - vorne dran.

Oliver

[Norbert (der_norbert)]

Oliver S. schrieb:
> Ist hier im Forum allerdings schwer zu erkennen.
> Die Langversionen der Optionen haben zwei - vorne dran.

Dafür gibt's »PRE«

Edit: Nur mal zum Test -- --version
Scheint mit Firefox und Debian-Stable auch zu funktionieren. Dieses 
›verschmelzen‹ zweier Striche zu einem Langen wird also ein Browser- 
oder ein Betrübssystem-Problem sein.

[Wulf D. (holler)]

gcc -- version funktioniert, wird vom configure Script auch verwendet. 
Aber es werden ein paar Zeilen später auch -v, -version etc verwendet.

Verstehe ich alles nicht.

Im configure Script steht z.B. dieser Abschnitt, vielleicht kommt es 
daher:

  case $ac_option in
  # Handling of the options.
  -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r)
    ac_cs_recheck=: ;;
  --version | --versio | --versi | --vers | --ver | --ve | --v | -V )
    printf "%s\n" "$ac_cs_version"; exit ;;
  --config | --confi | --conf | --con | --co | --c )
    printf "%s\n" "$ac_cs_config"; exit ;;
  --debug | --debu | --deb | --de | --d | -d )
    debug=: ;;

Aber am Ende macht es meiner Meinung nach überhaupt keinen Sinn sich mit 
dem configure Script näher auseinander zu setzen: ist automatengeneriert 
und parktisch nicht menschen-lesbar ist. Allein schon die schiere Länge 
von über 22000 Zeilen.

Aus den beiden Komponenten *Makefile.am*

AUTOMAKE_OPTIONS = foreign

EXTRA_DIST =    \
  drm.spec  \
  drm.spec.in

SUBDIRS = linux

rpm:  Makefile
  make dist
  $(RPMBUILD) -ta $(PACKAGE)-$(VERSION).tar.gz
  rm $(PACKAGE)-$(VERSION).tar.gz

und eben *configure.in* (moderner wäre configure.ac). erzeugen die 
Autotools wie autoconf, automake und aclocal dann das script configure, 
welches in der Kommandozeile gestartet, ein maschinenabhängiges makefile 
als Ergebnis liefern sollte.

Nehme an, dass in den mehr als 15 Jahre alten Scripten etwas zu heutigen 
Systemen inkompatibles schlummert.
Muss mich wahrscheinlich im Detail einarbeiten. Oder versuchen, Scripte 
für ein mir bekanntes Build-System zu finden (z.B. CMake).

[Harald K. (kirnbichler)]

Oliver S. schrieb:
> Finde den Unterschied…
> Ist hier im Forum allerdings schwer zu erkennen.

Nur wenn man die Wischversion auf dem Smartphone nutzt. Auf richtigen 
Webbrowsern wird ein Monospaced-Font verwendet, und da ist das sehr 
eindeutig zu erkennen.

Es gibt Gründe, warum man als Programmierer sowohl auf die Verwendung 
von Proportionalschrift als auch auf die Verwendung typographisch 
ansprechender Ligaturen verzichtet.

Sowas hier ist einer davon.

[Wulf D. (holler)]

Autotools

[Rolf M. (rmagnus)]

Wulf D. schrieb:
> gcc -- version funktioniert, wird vom configure Script auch verwendet.
> Aber es werden ein paar Zeilen später auch -v, -version etc verwendet.
>
> Verstehe ich alles nicht.

Du verrennst dich da in was. Du hast das am Anfang schon richtig 
erkannt:

Wulf D. schrieb:
> ch frage mich, ist das von Relevanz oder werden da einfach mehrere
> Abfragen nach der Compilerversion nur durchiteriert?

> Aber am Ende macht es meiner Meinung nach überhaupt keinen Sinn sich mit
> dem configure Script näher auseinander zu setzen: ist automatengeneriert
> und parktisch nicht menschen-lesbar ist.

Richtig. Dafür ist es auch gar nicht gedacht. Ich habe mir noch nie die 
Details eines configure-Skriptes angesehen.

> Nehme an, dass in den mehr als 15 Jahre alten Scripten etwas zu heutigen
> Systemen inkompatibles schlummert.

Sehr wahrscheinlich. Eigentlich sollte das configure-Skript die 
Kompatibilität prüfen und, falls nicht gegeben, das Problem nennen. 
Allerdings gibt es viele Projekte, in denen das nicht konsequent 
durchgezogen wurde.
Das Problem würde ich eher in der fehlenden libdfftw vermuten. Eine 
Datei mit dem Namen scheint es früher bei FFTW2 auf manchen 
Distributionen gegeben zu haben, was aber eigentlich einfach nur die 
libfftw selbst ist.

Harald K. schrieb:
> Oliver S. schrieb:
>> Finde den Unterschied…
>> Ist hier im Forum allerdings schwer zu erkennen.
>
> Nur wenn man die Wischversion auf dem Smartphone nutzt. Auf richtigen
> Webbrowsern wird ein Monospaced-Font verwendet, und da ist das sehr
> eindeutig zu erkennen.

Bei mir sieht es auf einem "richtigen Webbrowser" mit Monospace-Font aus 
wie im ersten Bild. Man kann es schon erkennen, aber es ist durchaus 
übersehbar.

> Es gibt Gründe, warum man als Programmierer sowohl auf die Verwendung
> von Proportionalschrift als auch auf die Verwendung typographisch
> ansprechender Ligaturen verzichtet.

Und es gibt einen Grund, warum man Code-Tags verwenden sollte (siehe 
zweites Bild):

> Sowas hier ist einer davon.

[Harald K. (kirnbichler)]

Rolf M. schrieb:
> Bei mir sieht es auf einem "richtigen Webbrowser" mit Monospace-Font aus
> wie im ersten Bild. Man kann es schon erkennen, aber es ist durchaus
> übersehbar.

Das war dann ein ganz "schlauer" Browser, der -- durch — ersetzte.

Mein Smartphone ersetzt auch gerne ... durch …
Ganz tolle Wurst.

[Wulf D. (holler)]

Rolf M. schrieb:
> Das Problem würde ich eher in der fehlenden libdfftw vermuten. Eine
> Datei mit dem Namen scheint es früher bei FFTW2 auf manchen
> Distributionen gegeben zu haben, was aber eigentlich einfach nur die
> libfftw selbst ist.
>
Danke, guter Hinweis. Habe mir die Quellen für libdfftw geladen und 
konnte die auch fehlerfrei bauen.
Jetzt muss ich die "nur" noch den alten Scripten unterschieben.

[Wulf D. (holler)]

Einen Schritt weiter, das makefile wird erzeugt und make / der Compiler 
lief fast durch.

Danke für die Hinweise!

[Johann L. (gjlayde)]

Wulf D. schrieb:
> Ich frage mich, ist das von Relevanz oder werden da einfach mehrere
> Abfragen nach der Compilerversion nur durchiteriert?

Ja.  Natürlich ist es von Relevanz ob bestimmte Features vorhanden sind 
oder nicht, und wie diese gegebenenfalls anzusprechen sind.  Es ist ja 
Sinn & Zweck von configure, das abzufragen.

Die Fehlermeldungen an sich sind nicht schlimm, ist eben die Reaktion 
von GCC auf nen bestimmten Test.

Wenn ein configure mit nem Fehler abbricht, dann durchsucht man 
config.log besser vom Ende her statt von Anfang an.  Ansonsten hat man 
da kiloweise unkritisvche Fehlermeldungen zu durchforsten.

Zunächst ist aber mal zu beurteilen, ob die stdout Ausgabe von configure 
wie erwartet ist, und ob alle strikt benötigten Vorbedingungen richtig 
detektiert wurden.  Und natürlich, ob alle benötigten Pakete / Libs 
vorhanden sind.

[Wulf D. (holler)]

Ja danke, habe mich so langsam mit den Autotools angefreundet und kann 
den configure log interpretieren.
Habe mehrere Builds mit verschiedenen Konfigurationen erstellen können.

Steigen leider alle nach dem Start aus, immer irgend was mit 
Audio-Treibern. Sicher Inkompatibilitäten der alten SW mit aktuellem 
Audiosystem. Auch portaudio kann das nicht lösen.
Aber ok, war ein Versuch wert.

[Rolf M. (rmagnus)]

Kommt drauf an, wie die Software auf die Soundkarte zugreift. Es wäre 
praktisch, wenn es etwas genauer ginge als "irgend was mit
Audio-Treibern". Die Art des Zugriffs auf die Soundkarte wurde über die 
Jahre mehrfach geändert. Wenn das noch auf das alte /dev/dsp zugreift, 
musst du dein Programm mit sowas wie padsp starten. Es könnte aber z.B. 
auch Jack nutzen. Dann müsstest du den jackd starten, beispielsweise 
über qjackctl.