[Erledigt] Freetz 1.1-Compilierung bricht ab mit no: command not found

[ranafarid]

Hallo zusammen,

ich versuche den aktuellen trunk die aktuelle version 1.1 (svn rev 3858 ) zu compilieren, er bricht aber beim Übersetzen der gio mit folgendem output ab:

Making all in gio
make[3]: Betrete Verzeichnis '/home/micha/Software/freetz_svn/freetz-stable-1.1/source/glib-2.18.2/gio'
no --prefix=_gio_marshal ./gio-marshal.list --header --internal > gio-marshal.h.tmp && \
          mv gio-marshal.h.tmp gio-marshal.h
/bin/bash: no: Kommando nicht gefunden.
make[3]: *** [gio-marshal.h] Fehler 127
make[3]: Verlasse Verzeichnis '/home/micha/Software/freetz_svn/freetz-stable-1.1/source/glib-2.18.2/gio'
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlasse Verzeichnis '/home/micha/Software/freetz_svn/freetz-stable-1.1/source/glib-2.18.2'
make[1]: *** [all] Fehler 2
make[1]: Verlasse Verzeichnis '/home/micha/Software/freetz_svn/freetz-stable-1.1/source/glib-2.18.2'
make: *** [source/glib-2.18.2/glib/.libs/libglib-2.0.so.0.1800.2] Fehler 2

Übersetzt wird für eine 7170 mit replace kernel, die .config ist angehängt.

Kann mir jemand helfen?

Danke,
Michael

 

[Silent-Tears]

Zumindest deine Pfade sehen nach 1.1 aus, allerdings ausgechecked aus dem svn.

 

[olistudent]

Hi.
Mit welchem System baust du denn? Kannst du mal bitte den Inhalt von source/glib-2.18.2/config.log anhängen?

MfG Oliver

 

[ranafarid]

[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
Hallo Oliver,

ich baue auf Ubuntu 9.10.

config.log ist dran.

[Beitrag 2:]
Sorry, 1.1 stimmt natürlich.

 

[Silent-Tears]

Dann korrigier das bitte auch oben, denn dort schreibst du trunk.

 

[olistudent]

Mir fällt gerade auf, dass "no" kein guter Suchbegriff für so eine Datei ist.

Ich würde tippen, dass da eine Abfrage die ein Binary liefern soll, stattdessen "no" liefert. Aber was da jetzt genau fehlt!?

MfG Oliver

 

[er13]

Wenn ich mich nicht irre, fehlt Dir glib-genmarshal. Lösung (ungetestet):

• ac_cv_path_GLIB_GENMARSHAL=no Zeile aus make/config.cache löschen
• libglib2.0-dev-Paket installieren (sudo apt-get install libglib2.0-dev)
• make glib2-dirclean und make

 

[ranafarid]

Wenn ich mich nicht irre, fehlt Dir glib-genmarshal. Lösung (ungetestet):

• ac_cv_path_GLIB_GENMARSHAL=no Zeile aus make/config.cache löschen
• libglib2.0-dev-Paket installieren (sudo apt-get install libglib2.0-dev)
• make glib2-dirclean und make

Das wars, jetzt ist das Image gebaut worden.
Danke an er13,

Michael

PS: (Wie) Kann ich das Thema auf erledigt setzen?

 

[gismotro]

PS: (Wie) Kann ich das Thema auf erledigt setzen?

Einfach im ersten Beitrag auf Ändern -> Erweitert gehen und ein [Erledigt] in den Kopf des Beitrages schreiben.

 

[olistudent]

@er13
Wie können wir das Problem verhindern? Da hat jetzt der genmarshal auf dem Host gefehlt? Ich glaub den bauen wir in unserer glib nicht mit!?

MfG Oliver

 

[er13]

@Oliver:
Hmm, keine Ahnung, muss mir das Ganze erst genauer anschauen. Eventuell genauso wie bei microperl, indem wir das Verhalten von glib-genmarshal mit einem Script nachahmen (sofern mit wenig Aufwand möglich) und dann configure mit ac_cv_path_GLIB_GENMARSHAL gesetzt aufrufen. Oder wir schauen, ob glib-genmarshal im Pfad ist und wenn nein, weisen den User darauf hin, dass er das devel-Paket installieren soll.

 

[Silent-Tears]

Ich würde auf letzteres tippen, und das ganze mit den Tests am Anfang des Builds mitchecken.
Evtl. lässt sich das prerequisite-script ja erweitern, und eine url anzeigen oder einen Text zu irgendwelchen Erklärungen...

 

[er13]

@Oliver & Lars:
hab' in 3869 und 3870 eine denkbare Lösung eingecheckt, bitte um Review

 

[Silent-Tears]

Sieht ziemlich sinnig aus. Eine Frage: Wo soll der Hint dan auftauchen? Vr oder nach den configure? Denn das ist mit ner Menge Text verbunden...
Weiter Frage: Der anfängliche Prerequisite-check ist damit ja fast unnötig, oder?

 

[RalfFriedl]

Sieht interessant aus. Eine Stelle, die ich nicht verstanden habe, ist

exit 1 [B]>/dev/null 2>&1[/B]

Außerdem ist es unnötige Schreibarbeit, $(PKG)_MISSING_PREREQ zu verwenden. Etwas einfaches wie MISSING tut es auch und macht es leichter zu lesen.
Statt $(SOURCE_DIR)/.$(pkg)-$($(PKG)_VERSION)-build-prereq-checked würde ich lieber $($(PKG)_DIR)/.build-prereq-checked nehmen, das hält das Source-Verzeichnis übersichtlicher. Das Verzeichnis sollte dann vor dem touch angelegt werden.

 

[er13]

@Lars:
Die Fehlermeldung und der Hint werden unmittelbar hintereinander angezeigt und zwar noch vor dem Entpacken der Sources, d.h. auch vor configure. Der Build-Prozess bricht dann sofort ab. Das letzte, was der User sieht, sind eben die Fehlermeldung und der Hint, damit sollten sie nicht zu übersehen sein.

Meine Lösung eignet sich für Paket-spezifische Abhängigkeiten und lässt sich nur im Rahmen der Übersetzung eines Pakets verwenden. Der anfängliche Prerequisite-check wird denke ich weiterhin für irgendwelche Sachen gebraucht, die nicht mit einem Paket was zu tun haben (z.B. tr wird gebraucht, um sowohl $(pkg) als auch $(PKG) zur Verfügung zu stellen) oder einfach von so vielen Paketen gebraucht werden, dass es vom Aufwand her gesehen einfacher ist, die Abhängigkeit einmal im Prerequisite-check zu überprüfen. Außerdem kann meine Lösung noch keine header-Dateien und keine Libraries checken.

@Ralf:
Könnte sein, dass das Umleiten der Ausgabe in der Tat überflüssig ist. Ist denke ich ein Überbleibsel bei mir im Kopf, die Korn-Shell, wenn ich mich nicht täusche, produziert bei exit irgendwelche Ausgaben.

$(PKG)_MISSING_PREREQ vs. MISSING: hast Recht, kann man vereinfachen.

$(SOURCE_DIR)/.$(pkg)-$($(PKG)_VERSION)-build-prereq-checked vs. $($(PKG)_DIR)/.build-prereq-checked: wollte ich ursprünglich auch so lösen, hab' dann aber gesehen, dass in der .unpacked-Regel das $(PKG)_DIR-Verzeichnis gelöscht wird. Und da der build-prereq-check noch vor dem Entpacken durchgeführt wird, wäre .build-prereq-checked damit weg, was wiederum zur Folge hätte, dass alles immer wieder aufs neue entpackt, übersetzt und so weiter wäre.

 

[RalfFriedl]

Vielleicht sollten wir noch ein eigenes Verzeichnis anlegen, in dem die ganzen Flag-Dateien abgelegt werden können.

 

[Silent-Tears]

Vielleicht sollten wir noch ein eigenes Verzeichnis anlegen, in dem die ganzen Flag-Dateien abgelegt werden können.

Eine ziemlich gute Idee.

@er13: Im prerequisite-check sind einige Paketspezifische Sachen als Warnung mit angegeben. Diese sollten wir dann vielleicht auf die einzelnen Pakete auslagern.