Autotools Fehlerlog auswerten

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

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

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?

Wulf D. schrieb:

Aber wo kommt das her?

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

Oliver

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'

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?

1

gcc -v

1

gcc --version

erzeugen zwei völlig unterschiedliche Ausgaben. Die Umleitung

1

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

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

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.

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:

1

  case $ac_option in

2

  # Handling of the options.

3

  -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r)

4

    ac_cs_recheck=: ;;

5

  --version | --versio | --versi | --vers | --ver | --ve | --v | -V )

6

    printf "%s\n" "$ac_cs_version"; exit ;;

7

  --config | --confi | --conf | --con | --co | --c )

8

    printf "%s\n" "$ac_cs_config"; exit ;;

9

  --debug | --debu | --deb | --de | --d | -d )

10

    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

1

AUTOMAKE_OPTIONS = foreign

2

3

EXTRA_DIST =    \

4

  drm.spec  \

5

  drm.spec.in

6

7

SUBDIRS = linux

8

9

rpm:  Makefile

10

  make dist

11

  $(RPMBUILD) -ta $(PACKAGE)-$(VERSION).tar.gz

12

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

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.

Autotools

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.

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.

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.

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

Danke für die Hinweise!

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.

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.

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.