Dbox2-Images mit gcc 4.x

[GetAway]

FYI: Ein mit gcc3 gebautes yadd mit CVS-Stand 13.4. läuft ohne Aufälligkeiten.

[rhabarber1848]

Hier läuft ein flash-neutrino-jffs2_lzma-2x, aktueller CVS-Stand, gcc-4.1.2/kernel 2.4, ohne Probleme.

[rhabarber1848]

gcc47_dbox2.diff

Mit diesem Patch ist es möglich, mittels cdk/configure --with-gcc47 ein dBox2-Image mit
Kernel 2.6.26.8, eglibc-2.15 und gcc-4.7.0 zu kompilieren, flash-neutrino-jffs2_lzma-2x
läuft hier seit 12h mit geringen Problemen, die vermutlich nichts mit gcc-4.7.0 zu tun haben.

Größenvergleich mit einem gcc-3.4.6/kernel 2.6-Image (Format: 3.4.6 vs. 4.7.0 vs. 4.7.0 +lto):

kleiner:

Code: Alles auswählen

/bin/neutrino         1677444 1051088  957064
/bin/nhttpd            448528  232132  213644
/bin/busybox           352928  344852  328960
/bin/sectionsd         273324  182084  169764
/bin/zapit             158220  133776  120732
/bin/links_g          2616708 2552260 2523648
/lib/libfreetype.so.6  290488  268292
/lib/libFLAC.so.8      231736  145384
/lib/libm.so.6         227796   88244 (in eglibc OPTION_EGLIBC_LIBM_BIG = n)

/lib/modules/2.6.26.8-dbox2/* 960kb vs. 924kb (jeweils mit strip-Patch)

größer:

Code: Alles auswählen

/lib/libc.so.6 797636 844196
/lib/libstdc++.so.6 735368 851992

kaum verändert:
/vmlinuz 992016 992831
Ist das Ergebnis zu erwarten? CONFIG_CC_OPTIMIZE_FOR_SIZE=y war jeweils aktiviert.

/usr/bin/du in cdkflash/root-neutrino-jffs2_lzma/
17584 vs. 16220 vs. 16091

[rhabarber1848]

Einige Erläuterungen zu Patches innerhalb meines Patches:

- apps/tuxbox/enigma/data/sysconfig/Makefile.am
eglibc bringt locale-Daten mit, daher ist zoneinfo.tar.bz2 nicht mehr notwendig

- cdk/config/eglibc.config
wir brauchen nicht alle in eglibc enthaltenen Funktionen

- cdk/config/u-boot.dbox2.h.m4
Flash-U-Boot benötigt kein NFS und kein longhelp. Anfangs hatte ich Probleme,
U-Boot mit gcc-4.7 zu kompilieren und dachte, der Code wird zu groß. Daher habe
ich die Funktionen testweise abgeschaltet, bis ich merkte, dass das Linker-Skript,
s.u., das Problem war. Der o.g. Patch ist dennoch weiterhin sinnvoll.

- cdk/make/bootstrap_dbox2_new.mk
bootstrap.mk sieht schon schlimm genug aus Vorlagen stamen von cross-lfs.org,
OpenWRT und crosstool-ng

- cdk/make/ftpd.mk
"OPTION_EGLIBC_UTMPX = n", s.o.

- cdk/make/linuxkernel.mk
die toolchain wird mit --with-sysroot=$(targetprefix) kompiliert

- cdk/Patches/eglibc.diff
RPC-Support, einer vieler ähnlicher Patches
Patch für Kompilierfehler bei OPTION_POSIX_REGEXP_GLIBC = n, Option später
wieder aktiviert, da diese doch benötigt wird

- cdk/Patches/gcc47-870-ppc_no_crtsavres.patch
Compile-Patch für gcc-4.7.0

- cdk/Patches/linux-2.6.26.4-dbox2.diff
Compile-Patch für kernel-2.6.26.8

- cdk/Patches/u-boot-2011.06.diff
Link-Patch, der den bis vor kurzem im Patch enthaltenen zusätzlichen
gcc-3.4.6 für Kernel & U-Boot zum Glück überflüssig macht

[Houdini]

hmm, gccs ab 4.5 können ja <link time optimierung>, das könnte man mal ausprobieren.
Vielleicht gibts ja noch einen kleinen Performanceschub.
Aber ob das auch beim ppc geht...?

[rhabarber1848]

Aber ob das auch beim ppc geht...?

vermutlich ja: http://sourceware.org/bugzilla/show_bug.cgi?id=12672#c8

[rhabarber1848]

hmm, gccs ab 4.5 können ja <link time optimierung>, das könnte man mal ausprobieren.

/bin/busybox wird ca. 5% kleiner und funktioniert noch, kurz in /tmp getestet.
/bin/neutrino ist nur noch 957132 statt 1051088 Byte groß, ~ 9% kleiner, binary nicht getestet.

Vielleicht gibts ja noch einen kleinen Performanceschub.

Schneller nicht, aber kleiner: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47916#c4

Ich baue mir ein neues flash image (das linken dauert nun wesentlich länger), dann
berichte ich über das Ergebnis, den o.g. Patch habe ich bereits aktualisiert, damit
kann eine lto-toolchain kompiliert werden.
Für den lto-Support bitte noch diesen Patch für aktuelle binutils testen: binutils-2.22.52_snap.diff

Mit der ULC-Version von gcc47_dbox2.diff wurde aber noch kein komplettes Image gebaut,
daher ist es bleeding edge

[rhabarber1848]

Mit der ULC-Version von gcc47_dbox2.diff wurde aber noch kein komplettes Image gebaut,
daher ist es bleeding edge

Patch nochmals aktualisiert, lto wird nun beim Image-bauen berücksichtigt.
Im obigen Posting habe ich die binary-Größen mit lto aktualisiert, eventuell
ist mit -fwhole-program an den richtigen Stellen noch mehr möglich.

PS: flash-neutrino-jffs2_lzma-all funktioniert

[Houdini]

*respekt*

[GetAway]

Dito, das liest sich alles sehr spannend. Habe gerade wenig Zeit, sonst hätte ich schon längst mitgetestet.

[msrx111]

Ich habe mal Enigma mit gcc4 gebaut. Und festgestellt, dass dann das laden von dboxide mit alternativem irq nicht mehr funktioniert. er meckert den Parameter irq=6 mit unknown option an...... Vielleicht kann das jemand nachvollziehen. Sagt mir was ich tun kann sollte sich das als Allgemeines Problem herausstellen. Ich weiß ja nicht ob ihr ein IDE zum testen habt. Ich hab jedenfalls zwei in meinen beiden Philips Boxen. Eins davon benötigt den alt. irq. Ich kann gerne für euch testen. Sagt mir wie ich euch helfen kann.....

Edit: flash-enigma-squashfs-lzma

[rhabarber1848]

Parameter irq=6 mit unknown option an

Lautet der Name des Parameters nicht irq6?
Weitere Probleme mit IDE@kernel 2.6 bitte hier weiter diskutieren:
http://www.tuxbox-cvs.sourceforge.net/f ... =7&t=48499

[msrx111]

Ich habe hier auf die schnelle falsch gepostet: Richtigerweise lautet es insmod dboxide irq6=1 und dann wird der Treiber nicht geladen sondern gemeckert...unknown option.. Ich hab jetzt mit Kernel 2.4 gebaut und gcc4. Sollte es daran liegen? Muss ich mit gcc4 auch 2.6 bauen? Bitte klärt mich auf.

Aber ich werde auf jeden Fall die Tage mal kernel 2.6 bauen und dann mal schauen....ob es dann funktioniert.

[GetAway]

Ich habe hier auf die schnelle falsch gepostet: Richtigerweise lautet es insmod dboxide irq6=1 und dann wird der Treiber nicht geladen sondern gemeckert...unknown option.. Ich hab jetzt mit Kernel 2.4 gebaut und gcc4. Sollte es daran liegen? Muss ich mit gcc4 auch 2.6 bauen? Bitte klärt mich auf.

Aber ich werde auf jeden Fall die Tage mal kernel 2.6 bauen und dann mal schauen....ob es dann funktioniert.

Vorher den ide-core geladen?

[msrx111]

die anderen Ide Module waren geladen. Alles okay....

[rhabarber1848]

Patch aktualisiert: gcc47_dbox2.diff

- gcc snapshot gcc-4.7-20120526
- Anpassung an eglibc trunk

[GetAway]

Patch aktualisiert: gcc47_dbox2.diff

- gcc snapshot gcc-4.7-20120526
- Anpassung an eglibc trunk

Code: Alles auswählen

Exportiert, Revision 18804.
rm -rf eglibc_svn
touch .deps/eglibc_version_check
false || mkdir -p /home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive && ( \
	wget -t 2 -T 10 -c -P /home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive http://crosstool-ng.org/hg/crosstool-ng/raw-file/856eacaf0e59/patches/eglibc/2_9/100-powerpc-8xx-CPU15-errata.patch || \
	wget -c -P /home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive http://www.tuxbox.org/cvsdata/files/100-powerpc-8xx-CPU15-errata.patch )
--2012-05-29 21:26:35--  http://crosstool-ng.org/hg/crosstool-ng/raw-file/856eacaf0e59/patches/eglibc/2_9/100-powerpc-8xx-CPU15-errata.patch
Auflösen des Hostnamen crosstool-ng.org... 140.211.15.107
Verbindungsaufbau zu crosstool-ng.org|140.211.15.107|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1511 (1,5K) [text/x-diff]
In »/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive/100-powerpc-8xx-CPU15-errata.patch« speichern.

100%[==================================================>] 1.511       --.-K/s   in 0s      

2012-05-29 21:26:36 (82,1 MB/s) - »/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive/100-powerpc-8xx-CPU15-errata.patch« gespeichert [1511/1511]

make: *** Keine Regel vorhanden, um das Target »/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive/300-001_ld_makefile_patch.patch«, 
  benötigt von ».deps/binutils«, zu erstellen.  Schluss.

[rhabarber1848]

Für den lto-Support bitte noch diesen Patch für aktuelle binutils testen: binutils-2.22.52_snap.diff

@GetAway: Hast Du auch diesen Patch genutzt? Er ist notwendig.

[GetAway]

Für den lto-Support bitte noch diesen Patch für aktuelle binutils testen: binutils-2.22.52_snap.diff

@GetAway: Hast Du auch diesen Patch genutzt? Er ist notwendig.

Bis jetzt nicht. Es wäre besser alle Patche immer im letzten Posting zu vereinen.

[rhabarber1848]

Es wäre besser alle Patche immer im letzten Posting zu vereinen.

In der nächsten Version des gcc-4.7-Patches wird der binutils-Patch enthalten sein...

PS: Erledigt: gcc47_dbox2.diff

[GetAway]

Jetzt hakt es hier. Alles neu ausgecheckt.

Code: Alles auswählen

make[3]: Betrete Verzeichnis '/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/build_gcc47/powerpc-tuxbox-linux-gnu/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
DEFINES='' HEADERS='' \
		../../../gcc-4.7-20120526/libgcc/mkheader.sh > tmp-libgcc_tm.h
/bin/sh ../../../gcc-4.7-20120526/libgcc/../move-if-change tmp-libgcc_tm.h libgcc_tm.h
echo timestamp > libgcc_tm.stamp
/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/build_gcc47/./gcc/xgcc -B/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/build_gcc47/./gcc/ -B/home/getaway/tuxbox/dbox2-2.4-test/cdk/powerpc-tuxbox-linux-gnu/bin/ -B/home/getaway/tuxbox/dbox2-2.4-test/cdk/powerpc-tuxbox-linux-gnu/lib/ -isystem /home/getaway/tuxbox/dbox2-2.4-test/cdk/powerpc-tuxbox-linux-gnu/include -isystem /home/getaway/tuxbox/dbox2-2.4-test/cdk/powerpc-tuxbox-linux-gnu/sys-include    -g -Os -O2  -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I../../../gcc-4.7-20120526/libgcc -I../../../gcc-4.7-20120526/libgcc/. -I../../../gcc-4.7-20120526/libgcc/../gcc -I../../../gcc-4.7-20120526/libgcc/../include -I../../../gcc-4.7-20120526/libgcc/../libdecnumber/dpd -I../../../gcc-4.7-20120526/libgcc/../libdecnumber -DHAVE_CC_TLS  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../gcc-4.7-20120526/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /home/getaway/tuxbox/dbox2-2.4-test/cdk/powerpc-tuxbox-linux-gnu/include/features.h:407:0,
                 from /home/getaway/tuxbox/dbox2-2.4-test/cdk/powerpc-tuxbox-linux-gnu/include/stdio.h:27,
                 from ../../../gcc-4.7-20120526/libgcc/../gcc/tsystem.h:88,
                 from ../../../gcc-4.7-20120526/libgcc/libgcc2.c:29:
/home/getaway/tuxbox/dbox2-2.4-test/cdk/powerpc-tuxbox-linux-gnu/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: No such file or directory
compilation terminated.
make[3]: *** [_muldi3.o] Fehler 1
make[3]: Verlasse Verzeichnis '/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/build_gcc47/powerpc-tuxbox-linux-gnu/libgcc'
make[2]: *** [all-target-libgcc] Fehler 2
make[2]: Verlasse Verzeichnis '/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/build_gcc47'
make[1]: *** [all] Fehler 2
make[1]: Verlasse Verzeichnis '/home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/build_gcc47'
make: *** [.deps/gcc] Fehler 2

[rhabarber1848]

gcc47_dbox2.diff

Patch aktualisiert:
- gcc snapshot gcc-4.7-201200602
- Anpassung von cdk/Patches binutils.diff an aktuellen binutils snapshot

@GetAway:
Das Problem scheint im Bereich 32/64-bit-System zu liegen, siehe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
Ich habe bis vor Kurzem auf Debian Wheezy 32bit kompiliert, nun nutze ich die
64bit-Variante davon und habe nirgendwo Probleme gehabt. Könntest Du bitte
Details zu Deinem System posten, damit ich die Situation nachstellen kann?

PS: https://bbs.archlinux.de/viewtopic.php? ... 06#p182606
Scheinbar können nicht alle 64bit-distros 32bit-Code produzieren...

[GetAway]

Ubuntu 10.04 auf VMware 32bit Windows XP

[rhabarber1848]

Ubuntu 10.04 auf VMware 32bit Windows XP

$ uname -a
Linux ubuntu 2.6.32-41-generic #89-Ubuntu SMP Fri Apr 27 22:22:09 UTC 2012 i686 GNU/Linux
$ ../../image/cdk/bin/powerpc-tuxbox-linux-gnu-gcc -dumpversion
4.7.1

Hier funktioniert "make bootstrap", installiert von ubuntu-10.04.4-alternate-i386.iso

[GetAway]

@rhabarber1848

Code: Alles auswählen

$ uname -a
Linux ubuntu 2.6.32-41-generic #89-Ubuntu SMP Fri Apr 27 22:22:09 UTC 2012 i686 GNU/Linux

Darauf habe ich jetzt aktualisiert. Jetzt haut der Patch daneben, obwohl ich ihn eben neu heruntergeladen habe.

Code: Alles auswählen

rm -rf cloog-0.16.3
touch .deps/libcloog_host
( rm -rf binutils-2.22.52 || /bin/true ) && bunzip2 -cd /home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive/binutils-2.22.52.tar.bz2 | TAPE=- tar -x && ( cd binutils-2.22.52 && chmod +w -R .; patch -p1 < ../Patches/binutils.diff ) && ( cd binutils-2.22.52 && chmod +w -R .;patch -p1 < /home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive/300-001_ld_makefile_patch.patch ) && ( cd binutils-2.22.52 && chmod +w -R .;patch -p1 < /home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Archive/300-012_check_ldrunpath_length.patch ) && ((for f1 in config.guess config.sub; do (for f2 in `find binutils-2.22.52 -name $f1`; do (test -e $f2 && rm -f $f2 && ln -s /home/getaway/tuxbox/tuxbox-cvs-2.4-test/cdk/Patches/$f1 $f2 && echo "updated $f2") done) done) || /bin/true) && ( rm -rf build_binutils || /bin/true ) && mkdir build_binutils
patching file bfd/Makefile.in
Hunk #1 succeeded at 323 (offset 3 lines).
patching file binutils/Makefile.in
Hunk #1 succeeded at 406 (offset 34 lines).
patching file configure
Hunk #1 succeeded at 2674 (offset 2499 lines).
patching file gas/Makefile.in
Hunk #1 succeeded at 282 (offset 4 lines).
patching file gprof/Makefile.in
Hunk #1 FAILED at 91.
1 out of 1 hunk FAILED -- saving rejects to file gprof/Makefile.in.rej
patching file ld/Makefile.in
Hunk #1 FAILED at 117.
Hunk #2 succeeded at 130 (offset 17 lines).
Hunk #3 FAILED at 321.
Hunk #4 succeeded at 1929 (offset 196 lines).
2 out of 4 hunks FAILED -- saving rejects to file ld/Makefile.in.rej
make: *** [.deps/binutils] Fehler 1