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

ralle_666 · 1 Jun 2015

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

JohnDoe42 · 1 Jun 2015

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

JD.

PeterPawn · 1 Jun 2015

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.

ralle_666 · 1 Jun 2015

OK, schonmal vielen Dank für eure Hilfe.
Werde wohl erstmal eine VM benutzen, bis ich dem Problem Herr werden kann.

MFG
Ralle

tasuma · 8 Jun 2015

Arch nutzt als default jetzt schon GCC-5.1 vorerst hilft da erstmal nur ein Downgrade auf GCC-4.9.2

qwertz.asdfgh · 8 Jun 2015

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.

Wabuo · 8 Jun 2015

Habe den selben Fehler - gibts ne Lösung außer der VM?
MfG Wabuo

ralle_666 · 9 Jun 2015

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

qwertz.asdfgh · 9 Jun 2015

ralle_666 schrieb:
... hatte leider nicht mehr die 4.9.2.

Das sollte eigentlich nicht als Ausrede durchgehen, kennst du die >ARM<? Nein, damit ist nicht die Prozessorarchitektur gemeint.

Hint:
http://seblu.net/a/arm/packages/g/gcc/

ralle_666 · 9 Jun 2015

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

er13 · 12 Jun 2015

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

ralle_666 · 19 Jun 2015

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

er13 · 20 Jun 2015

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.

ralle_666 · 21 Jun 2015

OK, danke für deine Antwort.

Hier ist die Logdatei:

er13 · 21 Jun 2015

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 $@

ralle_666 · 22 Jun 2015

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

andiling · 23 Jun 2015

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.

ralle_666 · 24 Jun 2015

@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

andiling · 24 Jun 2015

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)

ralle_666 · 25 Jun 2015

Klar, kein Problem.
Bitteschön!

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

Neuer User

Aktives Mitglied

IPPF-Urgestein

Neuer User

Neuer User

IPPF-Promi

Neuer User

Neuer User

IPPF-Promi

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Anhänge

Aktives Mitglied

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Anhänge

Statistik des Forums