Dbox2-Images mit gcc 4.x

[dbt]

Ok, man muss komplett neu bauen, dann rafft es das BS. Wegen der Segfaults könnte es wohl mehr an Neutrino selbst liegen. Das jetzt zu durchforsten, ist mir aber etwas zu anstrengend.

[GetAway]

Hallo

Ein Image mit gcc4.1.2 segfaulted bei mir immer noch. Ich habe mich mal drangemacht und die Ursache dafür gefunden.
Es liegt an der Freetype Version 2.1.4 mit der defaultmäßig gebaut wird. Bei mir kann ich es jederzeit damit nachbilden.
Warum es nur bei einigen Boxen auftritt entzieht sich meiner Kenntnis. Wahrscheinlich ist es ein Speicher- oder Timingproblem.

Es liegt an folgenden Zeilen, wenn < FT 2.1.8 gebaut wird.
fontrenderer.cpp

Code: Alles auswählen

	font.image_type       = ftc_image_grays;
	font.image_type      |= ftc_image_flag_autohinted;

Ab 2.1.8 greift die neue API Version von Freetype und ab da sollte es nicht mehr segfaulten. Allerdings habe ich bei meinen
Tests immer FT 2.3.9 und FT 2.1.4 benutzt.

Es gibt eine Lösung für Version 2.1.4. Allerdings wird dann anders gerendert und man müsste einige Zeilen Code
mit ifdef gcc4 auffüllen um die gewohnte Ansicht der Menüs hinzubekommen, da die Hintergrundbox der Buchstaben
um 4 Pixel höher wird als sonst und die Menüs in die Länge zieht; sprich der Zeilenabstand wird größer.

Getestet habe ich es mit der Änderung der obigen Zeilen in

Code: Alles auswählen

	font.image_type       = ftc_image_grays;
	font.image_type      |= ftc_image_flag_unhinted;

bzw.

Code: Alles auswählen

-	font.image_type       = ftc_image_grays;
font.image_type      = FT_LOAD_FORCE_AUTOHINT;

Die untere Variante wird schon mit 2.1.4 unterstützt. Man darf ja nicht vergessen das die Entwicklung mit FT 2.0.9
anfing und der Code der oberen Variante seitdem im CVS war. Wie gesagt, es wird anders gerendert und es segfaultet
dann nicht mehr. Den Unterschied der gerenderten Buchstaben wird man am TV nicht erkennen. Das muss man sich schon
mit einen Grafikprogramm ansehen. Auffallen werden nur die größeren Zeilenabstände, das Hochrutschen der Buchstaben
um 1 Pixel und das die Ziffern im Menü etwas kleiner sind.

Das kann man teils mit diesen Zeilen in fontrender.cpp anpassen...

Code: Alles auswählen

-	upper = halflinegap+ascender+3;   // we add 3 at top
-	lower = -descender+halflinegap+1; // we add 1 at bottom
+	upper = halflinegap+ascender;   // we add 3 at top
+	lower = -descender+halflinegap; // we add 1 at bottom

Dann noch nen Hack das alle Zeilen um 1 Pixel nach unten rutschen und schon kann man FT 2.1.4 problemlos mit ggc4
kompilieren, ohne das Neutrino abschmiert.

Trotzdem lohnt sich meiner Meinung nach dieser Aufwand nicht.
Besser ist es direkt eine neuere FT Version (2.3.9) zu nehmen, auch wenn diese um ca. 113KB größer wird(gcc4 kompiliert).
Eventuell sollte man nochmal die Version 2.1.8 versuchen, da diese unter gcc4 vielleicht etwas kleiner als die 2.3.9 wird.
Insgesamt wird bei mir das Image um ca 3% kleiner, wenn man mit gcc4.1.2 baut, trotz der größeren libfreetype.so.6.

[rhabarber1848]

Besser ist es direkt eine neuere FT Version (2.3.9) zu nehmen

Gibt es noch binary-only Plugins, die eine bestimmte Freetype-Version voraussetzen?

[rhabarber1848]

Ein Image mit gcc4.1.2 segfaulted bei mir immer noch. [...]
Es liegt an der Freetype Version 2.1.4 mit der defaultmäßig gebaut wird. [...]
Warum es nur bei einigen Boxen auftritt entzieht sich meiner Kenntnis. Wahrscheinlich ist es ein Speicher- oder Timingproblem.

Nutzt Du andere als die fonts aus dem CVS?

[GetAway]

Ich benutze nur die Schriften aus dem CVS.

[rhabarber1848]

Mit diesem (im Image ungetesteten) Patch (EDIT: Patch entfernt) konnte ich den Größenzuwachs
auf 73kb beschränken, evtl. ist noch mehr möglich.

In meinen Spark-Patches nutze ich Freetype 2.3.12, der o.g. Patch basiert auf diesem Codestand,
zusätzlich mit der bestehenden cdk/configure-Option --with-freetypeversion=current konnte
ich Neutrino kompilieren.

Wenn keine Einwände gegen Freetype 2.3 bestehen, könnte man über ein generelles Update nachdenken...

[GetAway]

Mit diesem (im Image ungetesteten) Patch libfreetype_current.diff konnte ich den Größenzuwachs
auf 73kb beschränken, evtl. ist noch mehr möglich.

Wahrscheinlich hast du die 73Kb auch nur mit gcc4 hinbekommen.
Neuere ggc-Versionen bringen vielleicht noch mehr.
Hattest du nicht schon mit gcc4.5.3 experimentiert? Ich habe in den letzten Commits
etwas davon gelesen, denke aber das sich das auf Spark bezog.

In meinen Spark-Patches nutze ich Freetype 2.3.12, der o.g. Patch basiert auf diesem Codestand,
zusätzlich mit der bestehenden cdk/configure-Option --with-freetypeversion=current konnte
ich Neutrino kompilieren.

Wenn keine Einwände gegen Freetype 2.3 bestehen, könnte man über ein generelles Update nachdenken...

Generell heisst jetzt für gcc3 und gcc4 Images?
Eventuell sollte man FT 2.3 auf gcc4 Images beschränken.

[rhabarber1848]

Wahrscheinlich hast du die 73Kb auch nur mit gcc4 hinbekommen.

Ja.

Neuere ggc-Versionen bringen vielleicht noch mehr.

Für Kernel 2.4 ist bei gcc 4.1 Schluss, siehe linux-2.4.37.11/include/linux/compiler.h

Hattest du nicht schon mit gcc4.5.3 experimentiert? Ich habe in den letzten Commits
etwas davon gelesen, denke aber das sich das auf Spark bezog.

Korrekt.

Eventuell sollte man FT 2.3 auf gcc4 Images beschränken.

Ja, in der aktuellen lokalen Version des Patches ist das bereits der Fall,
dort konnte ich noch ein paar KB mehr einsparen, Tests stehen noch
aus, ich lade den Patch demnächst in ULC hoch.

[GetAway]

Mit diesem (im Image ungetesteten) Patch libfreetype_current.diff konnte ich den Größenzuwachs
auf 73kb beschränken, evtl. ist noch mehr möglich.

Der Patch funktioniert auch mit dem mit dem aktuellen CVS-Stand, gebaut mit gcc4
und --with-freetypeversion=current(FT 2.3.9). libfreetype.so.6 wir dabei 362,3KB groß,
also nur um 52KB größer als in einem mit gcc3 und FT 2.1.4 gebautem Image.
Ein Yadd läuft hier ohne Probleme.

[Mourice]

Hi,

bitte mich jetzt nicht falsch verstehen ...

Aber baut bitte nicht alles um, weil "einer" ein Problem hat.

Ich kann behaupten, dass mindestens 400 Leute problemlos sind.

Da liegt es eher nahe ...

MfG

Edit:

Aber ich habe auch kein Problem damit, die Finger davon zu lassen ...

Also war mein Post mal wieder überflüssig ... sorry

[rhabarber1848]

libfreetype.so.6 wird dabei 362,3KB groß,

Patch aktualisiert, derzeitige Größe 305KB, 25KB größer.

EDIT: yadd-neutrino und flash-neutrino-jffs2_lzma-2x positiv getestet.

[GetAway]

@Mourice

Wenn Du weiterhin mit gcc3 Images baust, wird sich nichts ändern.
Wenn Du deine Images mit gcc4 baust, solltest du etwas offener der
Weiterentwicklung gegenüberstehen.

[Mourice]

@Mourice

Wenn Du weiterhin mit gcc3 Images baust, wird sich nichts ändern.
Wenn Du deine Images mit gcc4 baust, solltest du etwas offener der
Weiterentwicklung gegenüberstehen.

Hi,

dass meinte ich mit den "400" ... die benutzen nämlich gcc4 ohne Probleme.

Und ich bin glaube ich der einzige, der mit dem Thema "offen" umgeht ...

MfG

[rhabarber1848]

dass meinte ich mit den "400" ... die benutzen nämlich gcc4 ohne Probleme.

Das ist doch gut, allerdings hat GetAway schon Mitte letzten Jahres von segfaults
in Verbindung mit Freetype berichtet, sodass da sicher etwas dran ist.
Gegen ein Update auf FT 2.3 für gcc4 habe ich zudem nicht einzuwenden,
da dies auch für NeutrinoHD genutzt wird. Es hilft, beide repos einander
anzugleichen.

@GetAway: Behebt mein aktueller Patch die segfaults?

[GetAway]

@rhabarber1848

Die Segfaults habe ich nur mit FT 2.1.4. Ich werde demnächst noch 2.1.8 probieren, wegen der neueren API.
Mal schauen wie groß libfreetype wird und ob man die noch optimieren kann.

[rhabarber1848]

libfreetype.so.6 wird dabei 362,3KB groß

Patch aktualisiert, nach dem Deaktivieren weiterer, scheinbar nicht
genutzter Optionen, ist die Datei nur noch 266 KB groß,
flash-neutrino-jffs2_lzma-2x erfolgreich getestet.

PS: To-Do: Test mit Enigma und fx2-plugins

[GetAway]

Das hört sich sehr gut an. Gibt es dieses Optimierungspotential
auch für FT 2.1.4 und gcc3? Bis jetzt lief ein mit gcc3 und FT214
gebautes Tetris auch in einem gcc4 mit FT2.3.x + letzten Patch
gebautem Yadd.

[rhabarber1848]

Gibt es dieses Optimierungspotential auch für FT 2.1.4 und gcc3?

Möglicherweise, andererseits tendiere ich unter den gegebenen Umständen
derzeit eher dazu, FT 2.3.12 für die dBox2 zum Standard zu machen,
unabhängig von der compiler-Version. Einwände?

PS: libfreetype.so.6 mit meinem letzten Patch in einem gcc3-Image ist noch 270KB groß.

[rhabarber1848]

Folgender Patch behebt compile-Fehler mit gcc-4.4: EDIT: Patch ist im CVS
yadd-neutrino, kompiliert mit kernel 2.6, gcc-4.4.7 und eglibc-2.15 funktioniert hier
bereits, mehr dazu später, da noch einige Probleme mit mklibs und U-Boot/flash zu
beheben sind.

@seife: Könntest Du bitte insbesondere einen Blick auf die Fixes in
apps/tuxbox/tools/hotplug/hotplug.c werfen?

PS: Warum nicht gcc > 4.4.x? => http://article.gmane.org/gmane.comp.boo ... boot/98460

[seife]

Eine generelle Anmerkung:
* einen Returnwert zwar zuzuweisen aber dann nicht zu benutzen wird die nächste compilerversion (4.6, spätestens 4.7) dann anmeckern: "variable is set but not used". => Wenn das Ergebnis eh nicht gecheckt wird, dann einfach nach void casten: "(void)write(fd, buf, count);"
* die anderen Sachen in hotplug sehen OK aus, das war der übliche strncat-Fehler

[rhabarber1848]

* einen Returnwert zwar zuzuweisen aber dann nicht zu benutzen wird die nächste compilerversion (4.6, spätestens 4.7) dann anmeckern: "variable is set but not used".

Nach compile-Lauf mit gcc-4.7.0 habe ich folgenden Patch committed, ein gcc-4.1.2-Image läuft weiterhin:
http://article.gmane.org/gmane.comp.vid ... x.scm/3336
http://article.gmane.org/gmane.comp.vid ... x.scm/3337
http://article.gmane.org/gmane.comp.vid ... x.scm/3338
http://article.gmane.org/gmane.comp.vid ... x.scm/3339
http://article.gmane.org/gmane.comp.vid ... x.scm/3340
http://article.gmane.org/gmane.comp.vid ... x.scm/3341
http://article.gmane.org/gmane.comp.vid ... x.scm/3342
http://article.gmane.org/gmane.comp.vid ... x.scm/3343
http://article.gmane.org/gmane.comp.vid ... x.scm/3344
http://article.gmane.org/gmane.comp.vid ... x.scm/3345
http://article.gmane.org/gmane.comp.vid ... x.scm/3346
http://article.gmane.org/gmane.comp.vid ... x.scm/3347
http://article.gmane.org/gmane.comp.vid ... x.scm/3348
http://article.gmane.org/gmane.comp.vid ... x.scm/3349
http://article.gmane.org/gmane.comp.vid ... x.scm/3350
http://article.gmane.org/gmane.comp.vid ... x.scm/3351
http://article.gmane.org/gmane.comp.vid ... x.scm/3352
http://article.gmane.org/gmane.comp.vid ... x.scm/3353
http://article.gmane.org/gmane.comp.vid ... x.scm/3354
http://article.gmane.org/gmane.comp.vid ... x.scm/3355
http://article.gmane.org/gmane.comp.vid ... x.scm/3356
http://article.gmane.org/gmane.comp.vid ... x.scm/3357
http://article.gmane.org/gmane.comp.vid ... x.scm/3358
http://article.gmane.org/gmane.comp.vid ... x.scm/3359
http://article.gmane.org/gmane.comp.vid ... x.scm/3360
http://article.gmane.org/gmane.comp.vid ... x.scm/3361
http://article.gmane.org/gmane.comp.vid ... x.scm/3362

[Mourice]

Hi,

auf meinen Boxen läuft es mittlerweile garnicht mehr.
Nicht nur segfaults sondern auch in der Menü-Steuerung geht eigentlich "nichts" mehr.

Eigentlich "schade" ...

MfG

[rhabarber1848]

mittlerweile

Könntest Du das bitte etwas genauer beschreiben?

[Mourice]

mittlerweile

Könntest Du das bitte etwas genauer beschreiben?

Hi,

letzter "akzeptabler" Stand, der auch bei mir selber läuft ist vom 12.02.2012.

Mehr kann ich momentan leider nicht sagen, da im Moment soviele "Bäume" hier rumstehen, dass ich den Wald nicht mehr sehe.
(von "den Anderen" habe ich leider keine Rückmeldungen, sodass vielleicht auch der Stand vom 02.04.2012 auf der einen oder anderen Box noch sauber läuft - bei mir leider auch nicht mehr)

MfG

[rhabarber1848]

letzter "akzeptabler" Stand, der auch bei mir selber läuft ist vom 12.02.2012.

Änderungen seitdem umfassen u.a. die hardware sections.