[Gelöst] dropbear kompiliert nicht (rev. 1801)

[alpha1974]

Ich habe schon im trac-System ein Ticket aufgegeben, das aber wieder geschlossen wurde, weil das Problem gar nicht auftreten dürfte. Da sich mein System trotzdem stur anstellt, versuche ich es hier nochmal.

Neu ausgecheckte Freetz-Revision 1801 soll für Fritzbox 7170, 29.04.49, auf einem Gentoo AMD64 mit 2.6.24.1 Kernel kompiliert werden. Config-Datei im Anhang (umbenannt von .config in config.txt, um sie hochladen zu können).

make von dropbear bricht mit folgender Fehlermeldung ab:

PATH="/home/guenter/freetz-trunk/toolchain/target/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin" \
		make -j2 PROGRAMS="dropbear dbclient dropbearkey scp" MULTI=1 SCPPROGRESS=1 -C source/dropbear-0.50
make[1]: Entering directory `/home/guenter/freetz-trunk/source/dropbear-0.50'
/home/guenter/freetz-trunk/toolchain/target/bin/mipsel-linux-uclibc-gcc -I. -I. -I./libtomcrypt/src/headers/  -Os -pipe -march=4kc -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DDROPBEAR_SERVER -DDROPBEAR_CLIENT -DPROGRESS_METER -DDBMULTI_dropbear -DDBMULTI_dbclient -DDBMULTI_dropbearkey -DDBMULTI_scp -DDROPBEAR_MULTI   -c -o dbmulti.o dbmulti.c
/home/guenter/freetz-trunk/toolchain/target/bin/mipsel-linux-uclibc-gcc -I. -I. -I./libtomcrypt/src/headers/  -Os -pipe -march=4kc -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DDROPBEAR_SERVER -DDROPBEAR_CLIENT -DPROGRESS_METER -DDBMULTI_dropbear -DDBMULTI_dbclient -DDBMULTI_dropbearkey -DDBMULTI_scp -DDROPBEAR_MULTI   -c -o atomicio.o atomicio.c
In file included from libtomcrypt/src/headers/tomcrypt.h:67,
                 from includes.h:123,
                 from dbmulti.c:25:
./libtomcrypt/src/headers/tomcrypt_cfg.h:38: error: conflicting types for 'memcpy'
./libtomcrypt/src/headers/tomcrypt_cfg.h:39: error: conflicting types for 'memcmp'
./libtomcrypt/src/headers/tomcrypt_cfg.h:42: error: conflicting types for 'strcmp'
make[1]: *** [dbmulti.o] Fehler 1
make[1]: *** Warte auf noch nicht beendete Prozesse...
In file included from libtomcrypt/src/headers/tomcrypt.h:67,
                 from includes.h:123,
                 from atomicio.h:31,
                 from atomicio.c:30:
./libtomcrypt/src/headers/tomcrypt_cfg.h:38: error: conflicting types for 'memcpy'
./libtomcrypt/src/headers/tomcrypt_cfg.h:39: error: conflicting types for 'memcmp'
./libtomcrypt/src/headers/tomcrypt_cfg.h:42: error: conflicting types for 'strcmp'
make[1]: *** [atomicio.o] Fehler 1
make[1]: Leaving directory `/home/guenter/freetz-trunk/source/dropbear-0.50'
make: *** [source/dropbear-0.50/dropbearmulti] Fehler 2

Kurios: Auf dem gleichen System wurde vorher eine lauffähige 29.04.49-freetz-devel-1757M-Firmware problemlos kompiliert (weshalb ich davon ausgehe, dass alle Abhängigkeiten erfüllt sind; habe es auch nochmals im Wiki überprüft). Wie gesagt, die Fehlermeldung kommt mit einer "frischen" Revision. Any ideas?

Besten Dank,
alpha1974

 

[alpha1974]

Hmpf, falsches Forum. Bitte an einen Admin: Verschieben ins Freetz-Forum.

Danke!

 

[frank_m24]

Aber gerne doch ...

 

[alpha1974]

Workaround: make/config.cache löschen

Nach langem Herumprobieren habe ich folgenden Workaround gefunden.
Wenn die Datei make/config.cache gelöscht wird, läuft alles mit einem erneuten "make" fehlerfrei durch.

Vielleicht ist aus einem vorangegangenen Durchlauf (für ein anderes Paket?) in config.cache ein falscher Parameter gespeichert, der dann für dropbear übernommen wird?

Gruß
alpha1974

 

[olistudent]

Jetzt wäre natürlich noch interessant zu wissen, was genau in deiner config.cache drin stand. ;-)
Also das nächste Mal, wenn der Fehler auftrtitt bitte sichern und nich löschen.

MfG Oliver

 

[m.kress]

Hallo,
nachdem ich ständig irgendwelche Probleme beim Compilieren unter Open-Suse 10.2 habe und die Ursache nicht lokalisieren konnte, bin ich jetzt auf stinky umgestiegen. Habe jetzt auch genau diesen Fehler, allerdings beim Trunk 1943. Aber ein Löschen der make/config.cache hilft bei mir nicht.

Die make/config.cache hab ich aufgehoben, allerdings bringt die wohl nix. Ich habe jedoch bei meinen Compilierversuchen auf alternative Quellen von uClib und Busybox zurückgreifen müssen (identische Versionen, zumindest vom Dateinamen und Version).

Ich bin bald am Verzweifeln, habe ich doch gehofft mit Stinky zumindest diesen Unsicherheitsfaktor einer anderen Buildumgebung zu entfliehen.

Gruß
Markus

 

[Silent-Tears]

Ich bin bald am Verzweifeln, habe ich doch gehofft mit Stinky zumindest diesen Unsicherheitsfaktor einer anderen Buildumgebung zu entfliehen.

Hast du dein Stinky auch aktualisiert? Alle benötigten Pakete (siehe Wiki) installiert?

Denn bei mir geht das alles auch im Stinky.

 

[m.kress]

Ich nutze 1.06. Oder gibt's da noch irgendwo ein Update-Script?

Frisch installiert. Nur 1x svn co http://svn.freetz.org/trunk freetz-trunk und auch nur 1x make menuconfig.

Gruß
Markus

 

[Silent-Tears]

Ich nutze 1.06. Oder gibt's da noch irgendwo ein Update-Script?

Ein Update-Script? Klar. Das heisst apt-get und ist debian-spezifisch (und dessen Derivate).

Welche Packages du wie zu installieren hast, entnimm bitte der Doku (das wie) und dem Wiki (welche) oder den hier irgendwo im Forum zu findenden Thread zum Stinky-Linux.

 

[m.kress]

Ok, Danke! apt ist mir geläufig. Ich bin halt von einer works-out-of-the-Box-Distri ausgegangen und hab nur das README im Paket durchgelesen und das Freetz-Wiki. Vom angesprochene Thread hab ich deshalb nur die ersten Beträge überflogen.

Interessant: Hab mir jetzt nochmal aus einer anderen Quelle das uClibc-Paket gezogen und make dropbear-dirclean durchgeführt. Der make scheint jetzt durchzulaufen ohne Stinky vorher noch upzudaten. Waren für meine Pakete wohl zufällig alle Pakete drin.

Edit:
make ist jetzt durchgelaufen. Ich weis aber nicht, ob's nun am make/config.cache und anschließenden make dropbear-dirclean war oder uClibc-Paket aus der anderen Quelle. Werd aber trotzdem das Debian updaten.

Edit2:
Hab mal die Sourcen meiner ersten alternativen Quelle von uClibc und der zweiten vergleichen. Beide sind gleich. Daran hat's also nicht gelegen. Da es also nach dem Löschen von make/config.cache und einem make dropbear-dirclean funktioniert hat - und das ohne Stinky upzudaten - war die Lösung von alpha1974 doch korrekt (bis auf das fehlende dropbear-dirclean).

Im Anhang die config.cache, welche als Workaround gelöscht wurde. Vielleicht kann ja jemand was mit anfangen.

Gruß
Markus

 

[olistudent]

Kannst du bitte auch noch die funktionierende anhängen? Damit ich die Unterschiede sehen kann.

MfG Oliver

 

[m.kress]

Hier die funktionierende Version.

 

[olistudent]

Ich hab die beiden config.cache verglichen. Und mir sind einige Einträge aufgefallen, die für den Fehler in Betracht kommen. Leider weiß ich nicht welches Package diese Einträge verursacht. Daher wäre ein .config interessant, mit der der Fehler auftritt.

MfG Oliver

 

[m.kress]

Bin mir nicht 100%ig sicher, ob es einer der beiden war. Möglich ist es zumindest vom Zeitstempel her.

-rw-r--r--  1 kress users   10766  3. Mär 14:14 .config
-rw-r--r--  1 kress users   10777  3. Mär 14:08 .config.old

Gruß
Markus