[mc-4.6.2] cannot find input file: intl/Makefile.in

[hermann72pb]

Ich bekomme mit dem aktuellen trunk heute folgende Meldung:

....
config.status: creating doc/sr/Makefile
config.status: error: cannot find input file: intl/Makefile.in

ERROR: Build failed.
make: *** [source/target-mipsel_uClibc-0.9.29/mc-4.6.2/.configured] Fehler 1

Ich hatte bereits versucht "mc-dirclean" und "target-toolchain-dirclean" vergebens auszuführen. Demnächst stünde noch neu auschecken auf dem Programm.
Aber langsam geht es mir schon auf den Geist: Alle 2-3 Monate komplett neu auszuchecken. Tüftelt ihr dort so stark an toolchain und Co, oder woher kommt das? Früher hatte ich schon mal ein halbes bis ganzes Jahr ohne neu auszuchecken kompilieren können. Mittlerweile kann man es vergessen.

MfG

 

[sf3978]

...
Aber langsam geht es mir schon auf den Geist: Alle 2-3 Monate komplett neu auszuchecken. Tüftelt ihr dort so stark an toolchain und Co, oder woher kommt das?
...

Aber wir wissen doch, dass der trunk die Spielwiese der Freetz-Entwickler ist. Und das ist auch gut so. Manche checken wöchentlich, 1 bis 3 mal komplett neu aus.

 

[olistudent]

Ich hab die letzen Tage ein Version Bump für den mc gemacht. Warum da allerdings ein Makefile.in bei dir fehlen soll!?
Kann es sein, dass die autotools zur Erstellung benötigt werden und diese bei dir nicht vorhanden sind.

Mfg Oliver

 

[hermann72pb]

@sf3978: Dass man wöchentlich neu auscheckt und von vorne anfängt ist nicht gut. Normalerweise dürfte alles dank svn und Abhängigkeiten auch dann funktionieren, wenn man einfach make durchlaufen lässt.
@Oliver:

apt-get install autotools-dev
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
autotools-dev ist schon die neueste Version.

Läuft es denn bei dir mit der neusten Version durch?

MfG

 

[sf3978]

... dank svn und Abhängigkeiten auch dann funktionieren, wenn man einfach make durchlaufen lässt.

Kann schon sein. Bei meinen vielen Modifizierungen im trunk, funktioniert ein "svn up", eh nicht. Schon deshalb muss ich neu auschecken.

 

[er13]

Ich halte den Aufruf von autogen.sh für völlig überflüssig und habe es daher in 5514 entfernt

@hermann: läuft es jetzt bei Dir durch?
@oliver: was war denn der Grund für diesen autogen.sh-Aufruf (hast Du beim Version-Bump hinzugefügt)?

 

[olistudent]

Hm, ich meine, dass er sich beschwert hatte, dass kein configure-Skript vorhanden sei!?

MfG Oliver

edit:

configure: loading site script /home/oliver/fritzbox/freetz/trunk_i386/include/site/mipsel-linux-uclibc
configure: loading cache /home/oliver/fritzbox/freetz/trunk_i386/source/target-mipsel_uClibc-0.9.31/config.cache
configure: error: cannot find install-sh or install.sh in config "."/config

edit2: Nachdem ich das Paket automake1.10 installiert habe und die Symlinks passen geht es.

 

[hermann72pb]

@Oliver: Du hattest doch oben gefragt, ob autotools bei mir installiert sind. Das hatte ich überprüft und hier gepostet. Was das mit configure-Skript zu tun hat, weiß ich nicht. Du hast gefragt, ich habe geantwortet. Mehr ist es nicht.
@er13: Danke, jetzt ist es durchgelaufen! Ich werde gleich testet, ob mc dann auch läuft. An der gleichen Stelle hatte ich beim Durchlauf 2-3 Warnungen zum Thema gesehen, aber hoffentlich bleibt es nur bei den Warnungen.

Die Frage bleibt dennoch offen: Warum lief es bei Oliver auch mit autogen.sh durch und bei mir nicht?

 

[schlimmchen]

edit2: Nachdem ich das Paket automake1.10 installiert habe [...] geht es.

same here

Genauer: Ohne das automake1.10 läuft es bei mir nur, wenn autogen.sh ausgeführt wird. Mit o.g. Paket läuft es sowohl als auch.

 

[er13]

Wie ich schon mal gesagt gehabt habe... wir sollten es nach Möglichkeit vermeiden, autotools während des Build-Vorgangs aufzurufen. Ein Grund ist die nicht immer vorhandene Abwährtskompatibilität von diesen. Ein Paket, das mit autotools-XY erstellt wurde, muss für die Version (XY+1) eventuell angepasst werden - da haben wir definitiv keine Lust drauf (man erinnere sich an tcpdump und autoconf-2.64, mit autoconf-2.63 hat es noch funktioniert). Das soll der Entwickler des Pakets machen.

Edit: damit ist "automake-1.10 installieren" für mich die bessere Lösung

Edit2: automake-2.6x durch autoconf-2.6x ersetzt

 

[hermann72pb]

@er13: Kannst du bitte diejenigen hier wie mich, die nicht so tief in diesem Crosskompilieren stecken etwas aufklären. Und zwar in folgenden Punkten:
1. Wo soll denn automake-1.10 installiert sein? Auf dem Buildsystem? In meinem Fall ist es FREETZLINUX. Die Version 1.10 ist aber älter als 2.64 oder 2.63. Sollte man downgrade machen? Oder wie sollte man eure Diskussion zu automake interpretieren?
2. Du hast doch die Sourcen und make-Files von MC jetzt so angepasst, dass autogen.sh gar nicht aufgerufen wird und man somit automake-Problem umgehen kann. Warum bist du dann jetzt plötzlich dafür, automake anzupassen? Ich verstehe leider die logische Kette nicht.

Ich persönlich würde eher den Weg vorschlagen, wo man minimale Änderungen am Buildsystem braucht. Denn wenn wir ab jetzt automake-X.Y als zwingend voraussetzen verschaffen wir hier wieder einen Dauerrenner/Klassiker von den meist gestellten Fragen in IPPF.
Natürlich kann Lars eine angepasste Version von FREETZLINUX generieren, die eine passende Version von automake beinhaltet, aber nicht alle nutzen FREETZLINUX als Build und werden zwangsläufig die Frage hier stellen.

MfG

 

[er13]

1. Wo soll denn automake-1.10 installiert sein? Auf dem Buildsystem?

ja

In meinem Fall ist es FREETZLINUX. Die Version 1.10 ist aber älter als 2.64 oder 2.63.

da habe ich mich mit dem Beispiel vertan, es soll automake-1.1x und autoconf-2.6x heißen. D.h. automake-1.10 und autoconf-2.6x installieren.

dass autogen.sh gar nicht aufgerufen wird und man somit automake-Problem umgehen kann. Warum bist du dann jetzt plötzlich dafür, automake anzupassen? Ich verstehe leider die logische Kette nicht.

Hmm, ich bin gar nicht dafür, ich habe doch gesagt, dass wir keine Lust darauf haben, Programme an die neue automake-Version anzupassen und deswegen die Installation von automake in der notwendigen Version als bevorzugte Lösung ansehen, ich zumindest, die anderen Devs dürfen sich auch dazu äußern ;-)

Ich persönlich würde eher den Weg vorschlagen, wo man minimale Änderungen am Buildsystem braucht. Denn wenn wir ab jetzt automake-X.Y als zwingend voraussetzen verschaffen wir hier wieder einen Dauerrenner/Klassiker von den meist gestellten Fragen in IPPF.

ehrlich gesagt halte ich den Aufwand auf der User-Seite ein sudo apt-get install automake1.10 auszuführen für geringer als jedes 1.10er-Program an die Version 1.11 anzupassen.

Natürlich kann Lars eine angepasste Version von FREETZLINUX generieren, die eine passende Version von automake beinhaltet, aber nicht alle nutzen FREETZLINUX als Build und werden zwangsläufig die Frage hier stellen.

Auch wenn ich FREETZLINUX noch nie gesehen habe, vermute ich stark, dass es bereits 1.10 hat, denn sonst würde sich mc bei Dir nicht übersetzen lassen. Außerdem ist mc-4.6.2 nur in trunk enthalten und Du müsstest schon wissen, was es heißt ;-)

p.s. In Wirklichkeit ist es für mich eine Frage des Aufwandes, da machen wir alle lieber was wichtigeres, damit es endlich 1.2 gibt, als uns auto*-Tools zu beschäftigen.

 

[u.g]

Auch wenn ich FREETZLINUX noch nie gesehen habe, vermute ich stark, dass es bereits 1.10 hat

Version 1.11 sogar ... (jedenfalls nach den diversen apt-gets, z.B. auch apt-get [...] automake [...]) :

freetz@freetz-linux:~$ automake --version
automake (GNU automake) 1.11
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <[email protected]>
and Alexandre Duret-Lutz <[email protected]>.

 

[olistudent]

Es geht explizit um die Version 1.10:

sudo apt-get install automake1.10

MfG Oliver

 

[u.g]

Ich hatte mit meinem Freetzlinux und dem Trunk von gestern oder vorgestern und automake-1.11
jedenfalls kein Problem mc zu übersetzen.

EDIT:
Hatte folgende Optionen gewählt:
- internal editor
- subshell support
- online help
- use ncurses [...]