Erstellt vor 6 Jahren

Zuletzt geändert vor 5 Jahren

#1942 new task

Drop support for older uClibc-versions, use latest stable version on all boxes.

Erstellt von: er13 Verantwortlicher:
Priorität: normal Meilenstein: freetz-future
Komponente: toolchain Version: devel
Stichworte: Beobachter:
Product Id: Firmware Version:

Beschreibung

Advantages:

  • simplified maintenance: one version → changes are easier to test; no need to backport fixes to older versions (could be a very hard and time consuming task)
  • a lot of less important fixes (which we normally wouldn't backport) would become available to all boxes (in particular a lot of IPv6 fixes, the root cause of #819, and so on)

Disadvantages:

  • uClibc libraries would become a bit bigger
  • almost no information on binary compatibility of older uClibc-versions with the newer ones

0.9.28→0.9.33: untested, no information at all
0.9.29→0.9.33: successfully tested on 7170 for more than 6 months, no known issue
0.9.32→0.9.33: untested, expected to work without any problem

Änderungshistorie (10)

comment:1 Geändert vor 6 Jahren durch qwertz123

Hi,
I just found this ticket and wanted to leave a note regarding testing:

According to the µClibc release notes, 0.9.28 should be binary compatible to 0.9.29 (but this is untested) http://www.uclibc.org/oldnews.html:

l6 May 2007, uClibc 0.9.29 Released

[...] Again, this one should be binary compatible with the 0.9.28 series, but no one has explicitly tested this, so let us know! 

My two personal 7570's (Speedport W920V) are running fine with µClibc 0.9.33 since July 2012. They are fully customized (trunk builds, about once a month) and heavily used for telephony (POTS, DECT, VoIP, ffgtk monitor), ADSL and WLAN (repeater, base) so I guess 0.9.29 → 0.9.33 isn't a problem for this version of AVM's binaries.

comment:2 Geändert vor 5 Jahren durch MaxMuster

Habe mal (wegen "0.9.28→0.9.33: untested, no information at all") versucht, das auf meiner Eumex zu testen.

Sieht so schlecht nicht aus (keine intensiven Test, nur "generelle Funktion"). Einziges Problem war, dass die Box erstmal nicht mehr erreichbar war, was wegen fehlender Hardware für eine serielle Console bei der Eumex300 etwas blöd war.

Habe dann das Image im qemu gestartet und das Problem gefunden: Alle Hintergrundprozesse (multid und so) liefen nicht. Fehlermeldung war can't resolve symbol '__fork', das in der Firmware mit 0.9.28 von libpthread exportiert wurde.

Mit einer Änderung analog zu diesem Patch bei ersten Tests für 0.9.29 läuft die Box jetzt prinzipiell.

Die "Experten" könnten sicher auch was schickes basteln, wo dieses Symbol nur exportiert wird, wenn es für eine AVM-uclibc 0.9.28 Box gebaut wird oder so ;-).

Meine Teständerungen waren (aber Tests gemacht habe ich nur mit 0.9.33.2):

Index: toolchain/Config.in
===================================================================
--- toolchain/Config.in	(Revision 10946)
+++ toolchain/Config.in	(Arbeitskopie)
@@ -67,12 +67,12 @@
 	config FREETZ_TARGET_UCLIBC_0_9_32
 	bool "0.9.32.1"
 	depends on FREETZ_AVM_UCLIBC_0_9_32 \
-		|| ((FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE) && FREETZ_AVM_UCLIBC_0_9_29)
+		|| ((FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE) && (FREETZ_AVM_UCLIBC_0_9_29 || FREETZ_AVM_UCLIBC_0_9_28))
 
 	config FREETZ_TARGET_UCLIBC_0_9_33
 	bool "0.9.33.2"
 	depends on FREETZ_AVM_UCLIBC_0_9_33 \
-		|| ((FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE) && (FREETZ_AVM_UCLIBC_0_9_29 || FREETZ_AVM_UCLIBC_0_9_32))
+		|| ((FREETZ_BUILD_TOOLCHAIN || FREETZ_DL_TOOLCHAIN_OVERRIDE) && (FREETZ_AVM_UCLIBC_0_9_29 || FREETZ_AVM_UCLIBC_0_9_28 || FREETZ_AVM_UCLIBC_0_9_32))
 endchoice
 
 comment "CAUTION: Usage of an uClibc version higher than that used by AVM may lead to an unstable box"
Index: toolchain/make/target/uclibc/0.9.33.2/181-unhide__fork.patch
===================================================================
--- toolchain/make/target/uclibc/0.9.33.2/181-unhide__fork.patch	(Revision 0)
+++ toolchain/make/target/uclibc/0.9.33.2/181-unhide__fork.patch	(Revision 0)
@@ -0,0 +1,12 @@
+--- libpthread/linuxthreads.old/ptfork.c.ori	2013-08-18 18:28:59.623902089 +0200
++++ libpthread/linuxthreads.old/ptfork.c	2013-08-18 18:31:31.619908361 +0200
+@@ -95,7 +95,9 @@
+ 
+ extern __typeof(fork) __libc_fork;
+ 
++/*old firmwares need symbol __fork, so don't hide it
+ pid_t __fork(void) attribute_hidden;
++*/
+ pid_t __fork(void)
+ {
+   pid_t pid;

comment:3 Geändert vor 5 Jahren durch er13

In 11007:

unrar:

  • workaround vfwprintf related "bus error" reported in this thread
  • the actual reason seems to be a bug in uClibc, it would be better to fix it instead
  • refs #1942

comment:4 Geändert vor 5 Jahren durch dileks

Zuletzt geändert vor 5 Jahren von dileks (vorher) (Diff)

comment:5 Geändert vor 5 Jahren durch er13

In 11093:

download-toolchain:

  • provide uClibc-0.9.33 based download-toolchain for big-endian/uClibc-0.9.32.x/kernel-2.6.32.x based boxes - EXPERIMENTAL
  • refs #1939, refs #1942

comment:6 Geändert vor 5 Jahren durch er13

In 11094:

download-toolchain:

  • provide uClibc-0.9.33 based download-toolchain also for little-endian/uClibc-0.9.32.x/kernel-2.6.32.x based boxes - EXPERIMENTAL
  • refs #1939, refs #1942

comment:7 Antworten: Geändert vor 5 Jahren durch er13

Zu den Bedenken bzgl. der binären Kompatibilität: ich betreibe seit mittlerweile fast 2 Jahren alle Boxen in meiner Familie mit 0.9.33 (0.9.29→0.9.33 und 0.9.32→0.9.33) und habe keine Probleme, die auf die binäre Inkompatibilität zurückzuführen wären. Es ist zwar kein Beweis, jedoch ein Erfahrungswert, der hoffen lässt. In den Release Notes zu 0.9.29 steht, dass 0.9.29 zu 0.9.28 binär kompatibel sein soll, d.h. es sind in Erwartung nur die etwas blöden Probleme wie __fork oben zu lösen.


Was spricht in erster Linie dafür 0.9.33 auf alle Boxen zu bringen - eine Unmenge an Bugs in den älteren Versionen, die dazu führen, dass manche Pakete einfach nicht funktionieren (z.B. unrar, asterisk). Man vergleiche auch, wie viele Bugs die letzte releaste 0.9.33-Version hat (all diese sind auch in den älteren Versionen vorhanden): buildroot, freetz, alpinelinux.


Welche Anpassungen sind meiner Meinung nach notwendig:

  • aktuell sind TARGET_TOOLCHAIN-Symbole (und somit die Target-Toolchain) so definiert. D.h. würde man für alle Boxen 0.9.33 verwenden, würde das dazu führen, dass diese Symbole für alle MIPSEL und für alle MIPS Boxen denselben Wert haben, d.h. dieselbe Target-Toolchain verwenden - als Beispiel, 7170, 7270v1 und 7270v2. Das geht jedoch nicht, weil alle diese Boxen unterschiedliche Kernel-Versionen verwenden und uClibc streng genommen kernel-Version spezifisch ist. Problem kann gelöst werden, indem man die Kernel-Version mit in den Target-Toolchain-"Namen" aufnimmt. Nebenbei gesagt, dass es in freetz eine funktionierende "gemeinsame" Toolchain für 2.6.13/2.6.19 und für 2.6.28/2.6.32 gibt, ist pures Glück, uClibc ist Kernel-Version spezifisch - diese Versionen scheinen syscall-kompatibel zu sein.
  • Zweites Problem ist 0.9.28. Die uClibc-.configs für alle Versionen ≥ 0.9.29 sind miteinander kompatibel. Nur 0.9.28 tanzt da aus der Reihe (locale-Funktionen sind in dieser nicht vorhanden). Wir könnten dies ignorieren, würden aber damit die Größe der uClibc für alle 0.9.28-based Boxen erhöhen. Das ist nicht gut, da es ausschließlich ältere Boxen mit wenig Flash sind. Denkbare Lösung: das die Inkompatibilität verursachende Symbol analog NPTL mit in den Target-Toolchain-"Namen" aufnehmen.
  • Drittes Problem ist 0.9.28 ;-), konkret das __fork-Symbol. Könnte etwas dirty auf Basis des Symbols für das erstere der beiden 0.9.28-Probleme gelöst werden.
  • Alternative Lösung für 0.9.28-Boxen, könnte die sein, dass man bei diesen bei 0.9.28 bleibt und auf 0.9.33 verzichtet.

Das Anpassen des Namens für die Target-Toolchain bedarf natürlich einer Aktualisierung aller download-toolchains.

In erstem Schritt würde ich nicht wirklich den Support für ältere uClibc-Versionen entfernen, sondern es weiterhin mitanbieten (0.9.33 jedoch als default). Diese Wunsch würde allerdings dazu führen, dass die Anzahl der download-toolchains sich deutlich vergrößert.

comment:8 als Antwort auf: ↑ 7 Geändert vor 5 Jahren durch ralf

Replying to er13:

In den Release Notes zu 0.9.29 steht, dass 0.9.29 zu 0.9.28 binär kompatibel sein soll

Ich kann mich dunkel erinnern, dass wir mal versucht hatte, die Library zu ersetzen, speziell .28 → .29, und dass es damit Probleme gab. Ich weiß aber nicht mehr, was genau es war.

comment:9 Geändert vor 5 Jahren durch cuma

In erstem Schritt würde ich nicht wirklich den Support für ältere uClibc-Versionen entfernen, sondern es weiterhin mitanbieten (0.9.33 jedoch als default).

Solang ich die Version die AVM nutzt optional verwenden kann ist das okay. Dann können die anderen testen, und ich nehme die stabilere Version

Diese Wunsch würde allerdings dazu führen, dass die Anzahl der download-toolchains sich deutlich vergrößert.

Ist das ein Problem?

comment:10 als Antwort auf: ↑ 7 Geändert vor 5 Jahren durch er13

Replying to er13:

Was spricht in erster Linie dafür 0.9.33 auf alle Boxen zu bringen - eine Unmenge an Bugs in den älteren Versionen, die dazu führen, dass manche Pakete einfach nicht funktionieren (z.B. unrar, asterisk). Man vergleiche auch, wie viele Bugs die letzte releaste 0.9.33-Version hat (all diese sind auch in den älteren Versionen vorhanden): buildroot, freetz, alpinelinux.

Interessanter Thread bzgl. fehlender uClibc-Releases: http://lists.uclibc.org/pipermail/uclibc/2014-February/048252.html

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.