[Problem] freetz "make" bricht unter Archlinux mit Fehlern ab

ralle_666

Neuer User
Mitglied seit
4 Jan 2013
Beiträge
19
Punkte für Reaktionen
0
Punkte
0
Hallo!

Ich wollte nach längerer Zeit mal wieder ein neues Image für meine 7490 bauen. Leider bricht make bei mir mit folgendem Fehler ab:
Code:
make[1]: Verzeichnis „/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools“ wird betreten
sed -e 's/#define SQUASHFS_MINOR\t\t\t1/#define SQUASHFS_MINOR\t\t\t76/g' squashfs_fs.h > squashfs_fs-lzma.h
gcc -I. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -g   -c -o read_fs.o read_fs.c
gcc -I. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -g   -c -o sort.o sort.c
sed -e 's/squashfs_fs\.h/squashfs_fs-lzma.h/g' unsquashfs.c > unsquashfs-lzma.c
sed -e 's/squashfs_fs\.h/squashfs_fs-lzma.h/g' mksquashfs.c > mksquashfs-lzma.c
gcc -I. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -g   -c -o unsquashfs-lzma.o unsquashfs-lzma.c
gcc -I. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -g   -c -o mksquashfs-lzma.o mksquashfs-lzma.c
g++ unsquashfs-lzma.o -L/home/ralle/freetz/source/host-tools/lzma465 -llzma -o unsquashfs-lzma
g++ mksquashfs-lzma.o read_fs.o sort.o -L/home/ralle/freetz/source/host-tools/lzma465 -llzma -o mksquashfs-lzma
mksquashfs-lzma.o: In function `linux_opendir':
/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1311: undefined reference to `add_dir_entry'
mksquashfs-lzma.o: In function `encomp_opendir':
/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1326: undefined reference to `add_dir_entry'
/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1343: undefined reference to `add_dir_entry'
mksquashfs-lzma.o: In function `single_opendir':
/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1358: undefined reference to `add_dir_entry'
/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma.c:1378: undefined reference to `add_dir_entry'
collect2: Fehler: ld gab 1 als Ende-Status zurück
Makefile:10: die Regel für Ziel „mksquashfs-lzma“ scheiterte
make[1]: *** [mksquashfs-lzma] Fehler 1
make[1]: Verzeichnis „/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools“ wird verlassen
tools/make/squashfs2/squashfs2.mk:25: die Regel für Ziel „/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma“ scheiterte
make: *** [/home/ralle/freetz/source/host-tools/squashfs2.2-r2/squashfs-tools/mksquashfs-lzma] Fehler 2
Die Abhängigkeiten von freetz.org habe ich überprüft. Ebenso von dem veralteten AUR-Paket freetz-svn.
Ich habe den Quellcode mal komplett neu ausgecheckt und auch nur ein minimal Build schlägt fehl.
Und schon bin ich mit meinem Latein am Ende...
Mein System ist Archlinux 64bit.

Vielen Dank schonmal im Vorraus

MFG
Ralle
 
Vielleicht mal den Tip von hier testen ?
Grüße,

JD.
 
Wenn das das einzige Problem bleiben sollte, reicht es aus, in der Datei tools/make/Makefile.in die Zeile zu squashfs2 auszukommentieren, denn diese Version wird für eine 7490 nicht benötigt.

Die Frage, wieviel weiter Dich das bringt, steht auf einem anderen Blatt ...

Da es sich bei der beim Linken als fehlend bemängelten Funktion eigentlich um eine "inline"-Definition handelt (die auch nicht durch bedingte Übersetzung irgendwie modifiziert wird, zumindest nicht auf den ersten Blick), würde ich glatt darauf tippen, daß der von Dir verwendete C++-Compiler da etwas fundamental falsch versteht.

Womit wir dann schon bei der erhöhten Wahrscheinlichkeit sind, daß es im Anschluß auch bei weiteren Paketen Probleme geben könnte.

Das mit den Abhängigkeiten ist die eine Sache, die Versionen (inkl. der Optionen beim Build der jeweiligen Pacman-Pakete) müssen irgendwie auch stimmen ... wobei das mit dem inkompatiblen CPP-Compiler nur geraten ist, aber so richtig fällt mir keine andere Erklärung ein, warum der Linker eine inline-Funktion suchen sollte; die sollte eben "inline" schon in mksquashfs-lzma.o (das ist gleich das erste Object-File in der Liste für den Linker) vorliegen und der Compiler dafür ggf. nicht einmal ein externes Symbol generieren.

EDIT: In jedem Fall ist Dein g++ etwas abweichend konfiguriert, denn eigentlich müßte beim Übersetzen von unsquashfs-lzma schon eine Compiler-Warnung kommen:
Code:
unsquashfs-lzma.c: In function ‘create_inode’:
unsquashfs-lzma.c:560:5: warning: too many arguments for format [-Wformat-extra-args]
     ERROR("create_inode: could not create %s device %s, because you're not superuser!\n",
Damit müßte zumindest der verwendete Standard bei "-Wformat" bei Deinem CPP-Compiler abweichend sein (vielleicht sind es ja auch nur globale Einstellungen auf Deinem System) ... u.U. findet sich da auch die Ursache für die falsche "inline"-Behandlung.
 
Zuletzt bearbeitet:
OK, schonmal vielen Dank für eure Hilfe.
Werde wohl erstmal eine VM benutzen, bis ich dem Problem Herr werden kann.

MFG
Ralle
 
Arch nutzt als default jetzt schon GCC-5.1 vorerst hilft da erstmal nur ein Downgrade auf GCC-4.9.2
 
Das scheint aber kein generelles Problem zu sein, habe erst vor kurzem Freetz-Images (trunk) für die 7390 unter Arch gebaut ohne Probleme. Allerdings hatte ich vor ca. einem Monat ein Problem unter Arch mir ein Image für eine 7570 zu bauen, leider habe ich das Log/die Fehlermeldung nicht mehr da ich damals leider keine Lust auf Fehlersuche hatte und das Image dann einfach auf meinem PC mit Ubuntu 14.04 gebaut hatte.
 
Habe den selben Fehler - gibts ne Lösung außer der VM?
MfG Wabuo
 
Auf die Idee mit dem GCC-Update bin ich auch gekommen, hatte leider nicht mehr die 4.9.2. Sonst hätte ich ein downgrade durchgeführt und getestet...
 
Das ARM kannte ich wirklich noch nicht....
So, schnell ein downgrade gemacht und schon läuft ein Minimalimage ohne Fehler durch...

Vielen Dank für die Hilfe!!!
MFG
Ralle
 
@PeterPawn: gcc5 verwendet per default -std=gnu11 statt -std=gnu89 wie alle gcc-Versionen davor. -std=gnu11 verwendet die C99 inline Semantik. C89 und C99 inline Semantiken unterscheiden sich (s. hier ab "C language issues").

@alle mit gcc5: habe in r13163 einen möglichen Fix eingecheckt. Wäre nicht schlecht, wenn jemand berichten könnte, ob dieser hilft. Es ist nicht auszuschließen, dass es neben den squashfs-tools weitere Tools gibt, die gcc5 kompatibel gemacht werden müssen.
 
Hallo!
Hatte die Tage leider keine Zeit...

Habe versucht unter GCC5 ein Image zu bauen, bricht jetzt mit folgendem Fehler ab:

Code:
libtool: compile:  /home/ralle/freetz/toolchain/build/mips_gcc-4.8.4_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -DPACKAGE_NAME=\"sqlite\" -DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.8.10.2\" "-DPACKAGE_STRING=\"sqlite 3.8.10.2\"" -DPACKAGE_BUGREPORT=\"http://www.sqlite.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"sqlite\" -DVERSION=\"3.8.10.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DSTRERROR_R_CHAR_P=1 -DHAVE_POSIX_FALLOCATE=1 -I. -D_REENTRANT -D_GNU_SOURCE -D_REENTRANT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT sqlite3.lo -MD -MP -MF .deps/sqlite3.Tpo -c sqlite3.c  -fPIC -DPIC -o .libs/sqlite3.o
mv -f .deps/shell.Tpo .deps/shell.Po
mv -f .deps/sqlite3.Tpo .deps/sqlite3.Po
/bin/sh ./libtool --tag=CC   --mode=link /home/ralle/freetz/toolchain/build/mips_gcc-4.8.4_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -D_REENTRANT=1 -DSQLITE_THREADSAFE=1  -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -o sqlite3 shell.o sqlite3.o  -ldl -lpthread 
libtool: link: /home/ralle/freetz/toolchain/build/mips_gcc-4.8.4_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -D_REENTRANT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o sqlite3 shell.o sqlite3.o  -ldl -lpthread
mips-linux-uclibc-gcc: error: sqlite3.o: No such file or directory
Makefile:404: die Regel für Ziel „sqlite3“ scheiterte
make[1]: *** [sqlite3] Fehler 1

MFG
Ralle
 
Dieser Fehler hat nichts mehr mit GCC5 zu tun.

Mache bitte
Code:
make sqlite-distclean
make sqlite-precompiled 2>&1 | tee sqlite-precompiled.log
und hänge hier die dabei erzeugte Logdatei an.

p.s. Der eigentliche Fehler (der, der dazu führt, dass es kein sqlite3.o gibt) ist in der von Dir geposteten Ausgabe nicht zu sehen.
 
OK, danke für deine Antwort.

Hier ist die Logdatei:
 

Anhänge

  • sqlite-precompiled.log.txt
    18.7 KB · Aufrufe: 6
Sehr merkwürdig. Laut Deinen Logs wird erst versucht sqlite3 zu linken und erst danach wird sqlite3.o kompiliert. Und das obwohl Makefile.in klar und deutlich folgende Zeilen enthält (d.h. die Abhängigkeit "sqlite3: sqlite3.o" ist vorhanden):
Code:
sqlite3_DEPENDENCIES = sqlite3.$(OBJEXT)
sqlite3$(EXEEXT): $(sqlite3_OBJECTS) $(sqlite3_DEPENDENCIES) $(EXTRA_sqlite3_DEPENDENCIES)

Welchen Wert hat FREETZ_JLEVEL in Deiner .config? Wieviele CPUs/Kerne hat Dein Build-System? Der einzige Workaround, der mir momentan einfällt, ist:
Code:
Index: make/sqlite/sqlite.mk
===================================================================
--- make/sqlite/sqlite.mk	(revision 13178)
+++ make/sqlite/sqlite.mk	(working copy)
@@ -26,7 +26,7 @@
 $(PKG_CONFIGURED_CONFIGURE)
 
 $($(PKG)_LIB_BINARY): $($(PKG)_DIR)/.configured
-	$(SUBMAKE) -C $(SQLITE_DIR)
+	$(SUBMAKE1) -C $(SQLITE_DIR)
 
 $($(PKG)_BINARY): $($(PKG)_LIB_BINARY)
 	@touch -c $@
 
Die CPU hat 4 Kerne, wurden auch alle genutzt (FREETZ_JLEVEL=4).
Auf einem Kern, bzw. mit deinem Patch läuft es ohne Fehler durch.

MFG
Ralle
 
Info: Ich habe mal ein paar Images mit gcc-multilib-5.1.0-4 gebaut (für die 3490, 7390 und 7490), hat alles geklappt.
 
@andiling
Seit Revision r13163 ist GCC 5 auch nicht mehr das Problem. Benutzt du auch Archlinux? Wenn ja, könntest du bitte mal versuchen sqlite mit mehreren Kernen zu bauen (siehe Post #13)

MFG
Ralle
 
Meine Info war allgemeiner Natur.

Bei mir klappt der build mit 7490 SQLite v3.x ohne readline.

(Du kannst auch Deine .config hier posten, dann kann ich auch gerne mal die bei mir durchlaufen lassen)
 
Klar, kein Problem.
Bitteschön!
 

Anhänge

  • .config.txt
    66.8 KB · Aufrufe: 4
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.