Erstellt vor 4 Jahren

Geschlossen vor 3 Jahren

Zuletzt geändert vor 7 Monaten

#842 closed defect (fixed)

toolchain updates (binutils, gcc, uclibc,...)

Erstellt von: cuma Verantwortlicher: er13, oliver
Priorität: normal Meilenstein: freetz-1.2
Komponente: other Version: devel
Beobachter: Product Id:
Firmware Version:

Beschreibung

Habe ein Problem beim Bauen eines Images für die 7170 mit dem Trunk r4965. Kann mit meiner .config ein Image bauen, wenn ich dann aber zusätzlich "Enable IPv6 support"(und nur dies) aktiviere bekomme ich mit "FREETZ_VERBOSITY_LEVEL=0" die Meldungen aus der angehängten Logdatei. Wenn ich danach auf "FREETZ_VERBOSITY_LEVEL=2" ändere bricht make nicht mehr ab. Habe übrigens "FREETZ_JLEVEL=5".
Sorry falls die Infos etwas unganau sind, geht nicht besser…

Anhänge (43)

IPv6_7170_libiberty.log (18.7 KB) - hinzugefügt von cuma vor 4 Jahren.
VERBOSITY_LEVEL-2.log (4.1 KB) - hinzugefügt von cuma vor 4 Jahren.
FREETZ_JLEVEL-equal-3 .txt (190.2 KB) - hinzugefügt von cuma vor 4 Jahren.
FREETZ_JLEVEL-equal-1 - samba.txt (5.8 KB) - hinzugefügt von cuma vor 4 Jahren.
make-j-fixes.patch (10.4 KB) - hinzugefügt von er13 vor 4 Jahren.
ungetestet, test läuft noch
make-j-fixes-gcc433.patch (11.0 KB) - hinzugefügt von er13 vor 4 Jahren.
010-make-j-fixes.patch (8.2 KB) - hinzugefügt von oliver vor 4 Jahren.
gcc-4.4.4
0.9.28-Vorlage-930-backport_link_asneeded.patch (9.4 KB) - hinzugefügt von er13 vor 4 Jahren.
funktioniert noch nicht, das Erstellen von uclibc_nonshared.a müsste noch rückportiert werden
0.9.28-930-backport_link_asneeded.patch (9.2 KB) - hinzugefügt von er13 vor 4 Jahren.
target-toolchain-sysroot.patch (24.1 KB) - hinzugefügt von er13 vor 4 Jahren.
Verschieben funktioniert damit leider nicht, einfach nur eine etwas aktuelere Version
0001-target-toolchain-Add-download-URL-for-binutils-2.20..patch (962 Byte) - hinzugefügt von dileks vor 4 Jahren.
[PATCH] target-toolchain: Add download-URL for binutils-2.20.51.0.9
0001-binutils-target-Fix-GMP-and-MPFR-install-directories.patch (1.1 KB) - hinzugefügt von dileks vor 4 Jahren.
[PATCH] binutils-target: Fix GMP and MPFR install directories
testcase_gcc-target.sh (2.6 KB) - hinzugefügt von dileks vor 4 Jahren.
Added script to demonstrate which includes are used for build of gcc-target
backport_uclibc_locale_updates.patch (100.1 KB) - hinzugefügt von oliver vor 4 Jahren.
locale-generator.tar.bz2 (56.8 KB) - hinzugefügt von er13 vor 4 Jahren.
uClibc-locale-le-32-de_DE-en_US.tar.gz (27.6 KB) - hinzugefügt von er13 vor 4 Jahren.
Achtung: noch ungetestet
toolchain_uClibc-0.9.28_gcc-4.4.4.patch (1.6 KB) - hinzugefügt von oliver vor 4 Jahren.
Build uClibc-0.9.28 toolchain with gcc-4.4.4 (not working yet)
0.9.29-backport_nonpic_support.patch (9.7 KB) - hinzugefügt von er13 vor 4 Jahren.
noch ungetestet
generated.tar.gz (39.1 KB) - hinzugefügt von oliver vor 4 Jahren.
uClibc-avm.diff (15.2 KB) - hinzugefügt von oliver vor 4 Jahren.
Diff des AVM uClibc-0.9.29 Source gegen Original (Source 7270 04.86)
kernel_headers.patch (4.5 KB) - hinzugefügt von oliver vor 4 Jahren.
kernel_headers_er.patch (5.8 KB) - hinzugefügt von er13 vor 4 Jahren.
bin noch am testen, scheint aber mit allen Konfigurationen zu funktionieren (download-toolchain steht noch an)
download-toolchain_right-kernel-headers.patch (4.5 KB) - hinzugefügt von er13 vor 4 Jahren.
Die Download-Toolchain muss nach dem Anwenden des Patches neu gebaut werden
i386_toolchain.patch (3.5 KB) - hinzugefügt von oliver vor 4 Jahren.
Build i386 toolchain even on x64 host
download-toolchain_wo_headers.patch (1.5 KB) - hinzugefügt von oliver vor 4 Jahren.
minimize_required_glibc___i386_toolchain.patch (10.5 KB) - hinzugefügt von er13 vor 4 Jahren.
apgcc.patch (1.2 KB) - hinzugefügt von er13 vor 4 Jahren.
toolchain_right-kernel-headers.patch (8.4 KB) - hinzugefügt von er13 vor 4 Jahren.
korrigierte Version des right-kernel-header-Patches
toolchain_right-kernel-headers-v2.patch (7.3 KB) - hinzugefügt von er13 vor 4 Jahren.
etwas vereinfachte Version
objdump.txt (78.7 KB) - hinzugefügt von oliver vor 4 Jahren.
64-Bit Ubuntu Maverick mit -m32
download_toolchain_fix_scsi_headers.patch (2.1 KB) - hinzugefügt von oliver vor 4 Jahren.
logfile-7141-freetz_2010-12-29_201209 ip6tables.txt (1.8 KB) - hinzugefügt von cuma vor 4 Jahren.
logfile-7170-freetz_2010-12-29_201201 minicom.txt (5.0 KB) - hinzugefügt von cuma vor 4 Jahren.
logfile-7390-freetz_2010-12-29_201334 hd-idle.txt (1.6 KB) - hinzugefügt von cuma vor 4 Jahren.
config.log (8.4 KB) - hinzugefügt von por vor 4 Jahren.
config.log of config error for fakeroot
cosmetic_fixes.patch (3.8 KB) - hinzugefügt von oliver vor 3 Jahren.
So?
0001-Enable-IPv6-for-Linux-kernel-smaller-2.6.14.patch (2.2 KB) - hinzugefügt von dileks vor 3 Jahren.
Refreshed 011 Patch for uClibc (0.9.32)
0001-Add-MIPS32_4KC-and-MIPS32_24KC-to-target-cpu-arch.patch (1.6 KB) - hinzugefügt von dileks vor 3 Jahren.
Add MIPS32_4KC and MIPS32_24KC to target cpu arch (replaces 100+101 patches for uClibc)
fix_reduced_locale_set.patch (708 Byte) - hinzugefügt von oliver vor 3 Jahren.
list-of-uClibc-0932-patches.txt (3.3 KB) - hinzugefügt von dileks vor 3 Jahren.
List of post-0.9.32 uClibc patches (from 0.9.32 GIT branch)
0-9-32-patches_freetz-and-0932branch.tar.xz (13.2 KB) - hinzugefügt von dileks vor 3 Jahren.
uClibc-0.9.32 patchset (freetz + post-0.9.32 from upstream)
011-ipv6_defines_according_to_kernel_version.patch (2.3 KB) - hinzugefügt von dileks vor 3 Jahren.
v2: Renamed to 011-ipv6_defines_according_to_kernel_version.patch
add_uclibc_patches_dileks.patch (18.0 KB) - hinzugefügt von oliver vor 3 Jahren.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (400)

Geändert vor 4 Jahren durch cuma

comment:1 Geändert vor 4 Jahren durch cuma

Mit "FREETZ_VERBOSITY_LEVEL=2" bricht make viel später ab. Evlt durch das oben verursacht? Log häng ich auch an

Geändert vor 4 Jahren durch cuma

comment:2 Geändert vor 4 Jahren durch oliver

  • Zusammenfassung von Fehler bei make durch "libiberty" nach FREETZ_JLEVEL > 3 breaks toolchain compilation geändert

comment:3 Geändert vor 4 Jahren durch oliver

Closed duplicate #814.

comment:4 Geändert vor 4 Jahren durch cuma

Noch ein Log mit FREETZ_JLEVEL = 3. Funktioniert auch nicht

Geändert vor 4 Jahren durch cuma

comment:5 Geändert vor 4 Jahren durch cuma

Mit FREETZ_JLEVEL=1 läuft make bis samba:

Geändert vor 4 Jahren durch cuma

comment:6 Geändert vor 4 Jahren durch er13

Das mit libiberty scheint ein gcc-Bug zu sein, teilweise durch ein automake-Bug verursacht. Der Rest noch unbekannt, eventuell Folgen von libiberty, eventuell auch automake, eventuell was anderes.

  1. da und da

p.s. konnte das libiberty-Problem bei mir mit -j 16 reproduzieren.

Geändert vor 4 Jahren durch er13

ungetestet, test läuft noch

comment:7 Geändert vor 4 Jahren durch er13

So, bei mir ist es jetzt drei Mal durch - kein Fehler (iptables und samba waren dabei). Könnte natürlich auch Zufall gewesen sein, ohne Patch ist es auch nicht jedes Mal abgebrochen. @cuma: Wie schaut's bei Dir aus? Könntest Du den Patch bitte auch testen?

Geändert vor 4 Jahren durch er13

comment:8 Geändert vor 4 Jahren durch oliver

Bei mir funktioniert der Toolchain Build jetzt wieder. Soweit ich das gesehen habe war das Problem, dass bei uns mipsel-linux-uclibc/lib ein Symlink auf ../lib in der Toolchain ist. Dabei kommen sich die Targets install_to_libdir und install_to_tooldir in die Quere. Wenn man statt des Symlinks ein "richtiges" Verzeichnis erstellt, dann muss man "—with-sysroot" als configure Flag aufnehmen, sonst findet der ld die crti.o nicht, was dann noch weitere Änderungen nötig macht.

comment:9 Geändert vor 4 Jahren durch er13

Ich halte eher für unwahrscheinlich, dass es was mit "Symlink vs. echtes Verzeichnis" zu tun hat. Wenn Du Dir die Logdatei anschaust, die an dem gcc-Ticket hängt, dann siehst Du, dass es sich um genau das gleiche (libiberty-)Problem handelt, wie cuma es hat und wie ich es nachstellen konnte - alle Fehlermeldungen sind identisch, also tritt das Problem auch in den Umgebungen ohne Symlink auf. Schließlich haben die gcc-Entwickler den Bedarf gesehen, zu handeln und den Bug bei sich zu fixen. Meine Patches oben sind Rückportierungen des Fixes. Für 4.4.3 müsste ich den Patch noch erstellen. Da wollte ich Dich aber vorher fragen, ob Du vielleicht nicht gleich auf 4.4.4 updatest, nachdem die bei openwrt uns dafür quasi eine Vorlage geliefert haben.

comment:10 Geändert vor 4 Jahren durch cuma

Bauen funktioniert jetzt mit FREETZ_JLEVEL=5 und VERBOSITY_LEVEL=2. Samba auch. Und das Image bootet sogar freu

comment:11 Geändert vor 4 Jahren durch oliver

Ich bin dran.

binutils-2.19.1/2.20.51.0.9
uClibc-0.9.28/29/30.3/31
gcc-4.3.5/4.4.4

Läuft alles durch…

comment:12 Geändert vor 4 Jahren durch er13

(In [4972]) binutils:

  • don't install binutils in parallel
  • (hopefully) fixes weird build problem I managed to reproduce twice with JLEVEL 16
  • refs #842

comment:13 Geändert vor 4 Jahren durch er13

(In [4974]) kernel-gcc:

  • don't install it in parallel
  • fixes "failed to lock dir for editing! File exists"-problem (reproducible with JLEVEL 16)
  • refs #842

comment:14 Geändert vor 4 Jahren durch er13

(In [4975]) revise kernel-gcc patches:

  • add backport of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980 (refs #842)
  • add two patches from openwrt (910-mbsd_multi & pr16276-fix)
  • remove two ARM-related patches as I don't understand them and consider being incomplete (see corresponding openwrt patches)… we can even remove all ARM-related patches as AFAIK all FritzBoxes have MIPS processors
  • rename patches to better reflect their origin and purpose

comment:15 Geändert vor 4 Jahren durch er13

(In [4976]) gcc-4.2.4:

comment:16 Geändert vor 4 Jahren durch oliver

(In [4978]) * Update gcc-4.3.3 to 4.3.5

  • Update gcc-4.4.3 to 4.4.4
  • Don't use daily changing binutils version
  • Add uClibc-0.9.29/30 patches to fix compilation with gcc-4.3.x
  • refs #842

comment:17 Geändert vor 4 Jahren durch oliver

(In [4979]) * Update patches (continues last commit)

comment:18 Antworten: Geändert vor 4 Jahren durch oliver

@er13 Schaust du bitte, ob die neuen gcc-Versionen deinen Fix auch benötigen?

Ich hoffe, dass ich jetzt mit gcc-4.3.5 eine uClibc-0.9.29 Download-Toolchain hinbekomme… Um uClibc-0.9.28 mit gcc-4.3.5 zu bauen müsste der asneeded Patch zurück portiert werden. Da die Makefile-Struktur große Unterschiede aufweist hab ich mich daran nicht versucht.

Geändert vor 4 Jahren durch oliver

gcc-4.4.4

comment:19 Geändert vor 4 Jahren durch oliver

(In [4980]) * Delete obsolete patches after last commit (refs #842)

comment:20 Geändert vor 4 Jahren durch oliver

(In [4981]) * Toolchain: Forgot to update some gcc versions to 4.3.5 (refs #842)

comment:21 Geändert vor 4 Jahren durch er13

(In [4982]) gcc 4.3.5 & 4.4.4:

comment:22 als Antwort auf: ↑ 18 Geändert vor 4 Jahren durch er13

Replying to oliver:

Schaust du bitte, ob die neuen gcc-Versionen deinen Fix auch benötigen?

done, der Bug ist erst seit Version 4.5 behoben

comment:23 Geändert vor 4 Jahren durch cuma

Beim bauen von IPv6 für die 7270 erscheint mit r4986

Hardwire absolute paths into linker scripts (HARDWIRED_ABSPATH) [y] (NEW) 

Geändert vor 4 Jahren durch er13

funktioniert noch nicht, das Erstellen von uclibc_nonshared.a müsste noch rückportiert werden

Geändert vor 4 Jahren durch er13

comment:24 als Antwort auf: ↑ 18 Geändert vor 4 Jahren durch er13

Replying to oliver:

Um uClibc-0.9.28 mit gcc-4.3.5 zu bauen müsste der asneeded Patch zurück portiert werden.

Ich bin mir nicht sicher, ob der Patch im Falle von 0.9.28 überhaupt notwendig ist. Ich habe jetzt beim Rückportieren komplett auf uclibc_nonshared.a verzichtet, da atexit bei 0.9.28 in libc enthalten ist. Da es aber keine uclibc_nonshared.a gibt, gibt es aus meiner Sicht auch kein Bedarf an diesem —as-needed. Habe ich da was missverstanden? Welches Problem soll eigentlich der Patch lösen?

comment:25 Geändert vor 4 Jahren durch oliver

configure:2870: /home/oliver/fritzbox/freetz/trunk_3170/source/toolchain/target/gcc-4.4.4-uClibc-0.9.28/gcc-4.4.4-final/./gcc/xgcc -B/home/oliver/fritzbox/freetz/trunk_3170/source/toolchain/target/gcc-4.4.4-uClibc-0.9.28/gcc-4.4.4-final/./gcc/ -B/home/oliver/fritzbox/freetz/trunk_3170/toolchain/build/gcc-4.4.4-uClibc-0.9.28/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/bin/ -B/home/oliver/fritzbox/freetz/trunk_3170/toolchain/build/gcc-4.4.4-uClibc-0.9.28/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/lib/ -isystem /home/oliver/fritzbox/freetz/trunk_3170/toolchain/build/gcc-4.4.4-uClibc-0.9.28/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/include -isystem /home/oliver/fritzbox/freetz/trunk_3170/toolchain/build/gcc-4.4.4-uClibc-0.9.28/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/sys-include -o conftest -g -Os     conftest.c  >&5
+ eval '$CC' -o 'conftest$ac_exeext' '$CFLAGS' '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '>&5'
++ /home/oliver/fritzbox/freetz/trunk_3170/source/toolchain/target/gcc-4.4.4-uClibc-0.9.28/gcc-4.4.4-final/./gcc/xgcc -B/home/oliver/fritzbox/freetz/trunk_3170/source/toolchain/target/gcc-4.4.4-uClibc-0.9.28/gcc-4.4.4-final/./gcc/ -B/home/oliver/fritzbox/freetz/trunk_3170/toolchain/build/gcc-4.4.4-uClibc-0.9.28/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/bin/ -B/home/oliver/fritzbox/freetz/trunk_3170/toolchain/build/gcc-4.4.4-uClibc-0.9.28/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/lib/ -isystem /home/oliver/fritzbox/freetz/trunk_3170/toolchain/build/gcc-4.4.4-uClibc-0.9.28/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/include -isystem /home/oliver/fritzbox/freetz/trunk_3170/toolchain/build/gcc-4.4.4-uClibc-0.9.28/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/sys-include -o conftest -g -Os conftest.c
/home/oliver/fritzbox/freetz/trunk_3170/source/toolchain/target/gcc-4.4.4-uClibc-0.9.28/gcc-4.4.4-final/./gcc/libgcc_s.so: undefined reference to `dl_iterate_phdr'
collect2: ld returned 1 exit status
configure:2873: $? = 1

Die Stelle war die gleiche, deshalb hab ich gar nicht nach dem Fehler geschaut. Der ist aber ein anderer (vgl. PN). Sorry.

comment:26 Geändert vor 4 Jahren durch er13

(In [4992]) netpbm:

  • workaround parallel build problems (refs #842)

comment:27 Antwort: Geändert vor 4 Jahren durch dileks

Anmerkungen zu target-toolchain-sysroot.patch:

Bei Patches ist mir wichtig, gegen welchen Branch (hier: freetz-trunk) und Revision gebaut wird. Beim Toolchain-Bau solltest du neben gcc Version auch die Versionen von (u)Clibc und binutils angeben. Konkret: Mit welcher uClibc-Version hast du erfolgreich gebaut?

Nächste Frage, die sich mir immer stellt, wie nah will man an buildroot Upstream [0] bleiben?

Nach Diskussion auf IRC ist mir klar, dass du das BR2_TOOLCHAIN_SYSROOT Feature [1] ins freetz Buildsystem einbauen möchtest.

Z.B. gefällt mir die neue Variable "UCLIBC_DEVEL_SUBDIR:=uClibc_dev" in toolchain/make/target/uclibc/uclibc.mk [3] besser als in Upstream.

Nach gestriger Diskussion mit Oli, fehlt der SymLink zu den include Dateien?

[toolchain/make/target-toolchain.mk]
...
@ln -snf . $@/usr 
@mkdir -p $@/usr/$(REAL_GNU_TARGET_NAME) 
@ln -snf ../lib $@/usr/$(REAL_GNU_TARGET_NAME)/lib
+@ln -snf ../include $@/usr/$(REAL_GNU_TARGET_NAME)/include
...

Deinen Patch als Single-Patch finde ich ein wenig gross und nicht so einfach nachvollziehbar.
Der Blog-Artikel "On commit messages" [3] sei dir ans Herz gelegt :-).
Ich z.B. habe meine Änderungen in ein lokales GIT Repository eingepflegt.

cd freetz-trunk
revision=$(LC_ALL=C svn info | grep "Last Changed Rev" | awk {'print $4'})
echo $revision
git init && git add --ignore-errors ./ ; git commit -m "`basename $PWD` svn-rev$revision"

Ich baue gerade nochmal eine Toolchain, falls die abricht, versuche ich deinen Patch.

  • dileks -

P.S: Den Kommentar in [5] "# sysroot support works with gcc ≥ 4.2.0 only" könnte man noch in toolchain/make/gcc/gcc.mk einpflegen.

Referenzen:
-----------
[0] http://git.busybox.net/buildroot/
[1] http://git.busybox.net/buildroot/tree/toolchain/Makefile.in
[2] http://trac.freetz.org/attachment/ticket/842/target-toolchain-sysroot.patch
[3] http://who-t.blogspot.com/2009/12/on-commit-messages.html
[4] http://who-t.blogspot.com/2009/06/git-patches-from-tarballs.html
[5] http://git.busybox.net/buildroot/tree/toolchain/gcc/gcc-uclibc-4.x.mk#n20

comment:28 als Antwort auf: ↑ 27 ; Antwort: Geändert vor 4 Jahren durch er13

Replying to dileks:

Bei Patches ist mir wichtig, gegen welchen Branch (hier: freetz-trunk) und Revision gebaut wird. Beim Toolchain-Bau solltest du neben gcc Version auch die Versionen von (u)Clibc und binutils angeben. Konkret: Mit welcher uClibc-Version hast du erfolgreich gebaut?

Naja, ich habe die vorhandenden aber versteckten Optionen in menuconfig aktiviert und da gibt es halt momentan nur eine Möglichkeit, i.e. gcc-4.4 ist gleichbedeutend mit uClibc-0.9.31 und binutils-2.20.51.0.9

Nächste Frage, die sich mir immer stellt, wie nah will man an buildroot Upstream [0] bleiben? Nach Diskussion auf IRC ist mir klar, dass du das BR2_TOOLCHAIN_SYSROOT Feature [1] ins freetz Buildsystem einbauen möchtest.

Will ich nicht unbedingt, so war es einfacher nachzuvollziehen, an welchen Stellen freetz abweicht. Bei freetz ist im Laufe der Zeit schlicht und ergreifend ein Mischmasch aus BR2_TOOLCHAIN_SYSROOT=y und BR2_TOOLCHAIN_SYSROOT=n entstanden. Da wir in dem Bereich nicht wirklich fit sind, würde ich diese Option behalten wollen, weil der Vergleich mit Ursprung dann einfacher wird.

Nach gestriger Diskussion mit Oli, fehlt der SymLink zu den include Dateien?

mache ich rein, wobei bei 4.4 hat mich das Fehlen von diesem nicht gestört

Deinen Patch als Single-Patch finde ich ein wenig gross und nicht so einfach nachvollziehbar.

Streng genommen, hast Du Recht :) Aber ich rede mich damit raus, dass ich noch Familie, einen Vollzeit-Job habe (und nächste Woche geht's noch auf Dienstreise, i.e. ich noch packen muss) und mir für die klare Trennung schlicht und ergreifend die Zeit fehlt. Ich bin einfach alle Makefiles durchgegangen und sofort alles, was mir aufgefallen ist, korrigiert, basta :)

Den Kommentar in [5] "# sysroot support works with gcc ≥ 4.2.0 only" könnte man noch in toolchain/make/gcc/gcc.mk einpflegen.

Oder komplett rausschmeissen, da wir sowieso kein gcc < 4.2.0 mehr haben

comment:29 Antwort: Geändert vor 4 Jahren durch er13

Andere Frage, wie baut Ihr 0.9.30 eigentlich? In uClibc/extra/locale/ wird versucht uClibc-locale-20081111-32-el.tgz runterzuladen und diese fehlt auf http://www.uclibc.org, ich habe jetzt einfach uClibc-locale-030818.tgz dopplet kopiert, damit geht es.

Wir haben übrigens Einsparpotential, indem wir locale selbst bauen und die locales, die wir definitiv nicht brauchen, rausschmeissen.

comment:30 als Antwort auf: ↑ 28 Geändert vor 4 Jahren durch dileks

Mir geht es mehr darum eine gemeinsame Codebase für die Toolchain Sache zu haben. So kann man effektiver und gemeinschaftlicher arbeiten. Für mich hat das bisher bedeutet meine Änderungen für freetz-trunk svn-rev4202 für jetzt anzupassen. Mit svn-rev4992 plus deinem Patch als neue Codebase könnte ich mich arangieren. Diskutieren halte ich für besser im IRC :-)

Ja, da geb ich dir Recht Zeit ist rar… Man sollte aber die Zeit des anderen nicht unnötig verschwenden.

BTW, wie kann ich Patches an dieses Ticket anfügen?

  • dileks -

comment:31 als Antwort auf: ↑ 29 Geändert vor 4 Jahren durch dileks

Replying to er13:

Andere Frage, wie baut Ihr 0.9.30 eigentlich? In uClibc/extra/locale/ wird versucht uClibc-locale-20081111-32-el.tgz runterzuladen und diese fehlt auf http://www.uclibc.org, ich habe jetzt einfach uClibc-locale-030818.tgz dopplet kopiert, damit geht es.

Wir haben übrigens Einsparpotential, indem wir locale selbst bauen und die locales, die wir definitiv nicht brauchen, rausschmeissen.

Full ACK. Ich habe die uClibc-Locales ohne "pregenerated locale data" erfolgreich gebaut!

Bedarf Änderungen an der Config.mod:

cd freetz-trunk
CONFIG_MOD="toolchain/make/target/uclibc/Config.mod.0.9.30.3"
sed -i -r 's/UCLIBC_PREGENERATED_LOCALE_DATA=y/\# UCLIBC_PREGENERATED_LOCALE_DATA is not set/g' $CONFIG_MOD
sed -i -r 's/UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA=y/\# UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA is not set/g' $CONFIG_MOD

Der Kopier-Vorgang des Tarballs in uclibc.mk kann auskommentiert werden:

[toolchain/make/target/uclibc/uclibc.mk]
- cp -dpf $(UCLIBC_LOCALE_DATA) $(UCLIBC_DIR)/extra/locale/
+ #cp -dpf $(UCLIBC_LOCALE_DATA) $(UCLIBC_DIR)/extra/locale/
  • dileks -

P.S.: Patches + README bereits an Oli geschickt.

comment:32 Geändert vor 4 Jahren durch oliver

Ich hab das mit dem locale so aus dem AVM Makefile abgeschrieben. Wenn wir da Einsparpotential haben dann sollten wir das nutzen. Hast du was zum Nachlesen wie das geht?

Der include Pfad fehlt übrigens wirklich. Bei mir hat er ohne den Link keine Header gefunden.

Geändert vor 4 Jahren durch er13

Verschieben funktioniert damit leider nicht, einfach nur eine etwas aktuelere Version

Geändert vor 4 Jahren durch dileks

[PATCH] target-toolchain: Add download-URL for binutils-2.20.51.0.9

Geändert vor 4 Jahren durch dileks

[PATCH] binutils-target: Fix GMP and MPFR install directories

comment:33 Geändert vor 4 Jahren durch oliver

(In [4995]) * kernel toolchain: Bump binutils to 2.18 (refs #842)

comment:34 Geändert vor 4 Jahren durch oliver

(In [4996]) * kernel toolchain: Bump binutils to 2.18 (refs #842)

comment:35 Geändert vor 4 Jahren durch er13

(In [4999]) target-toolchain:

  • a second attempt to make target toolchain relocatable (based on patch provided by oliver on irc, i.e. all credits go to him)
  • use mpfr & gmp with all gcc versions, not only with 4.3.x (buildroot does the same)
  • add more uClibc/gcc combinations to menuconfig
  • introduce new makefile variable TARGET_TOOLCHAIN_GCC_MAJOR_VERSION (replaces menuconfig variable FREETZ_TARGET_GCC_VERSION_4_3)
  • introduce new makefile variable UCLIBC_DEVEL_SUBDIR, replace all occurrences of uClibc_dev with it
  • workaround uClibc-0.9.30 could not download precompiled locale files
  • minor dependency fixes and other cleanups in makefiles
  • replace rm with $(RM)
  • add MAKEINFO=true to workaround parallel build problems on systems with no makeinfo installed (…/missing makeinfo causes troubles)
  • whitespace changes/cleanups (sorry)
  • refs #842

comment:36 Geändert vor 4 Jahren durch dileks

[ Test-Cases für gcc-target ]

Fehler aus dem build.log:

.../toolchain/build/gcc-4.4.4-uClibc-0.9.30.3/mipsel-linux-uclibc/usr/include/bits/types.h:133:3: error: #error your machine is neither 32 bit or 64 bit ... it must be magical

Dazu olistudent (backlog IRC #fritzbox/randomirc.de, 06-Jun-2010):

[20:14:22] <olistudent> dileX: Das ist wieder der gcc-target bei dem es bei dir hängt? Bei mir wurde da der Host gcc mit den Includes des mipsel gcc gefüttert. Das kann natürlich nicht gut gehen. Da scheint was mit den Variablen nicht richtig zu sein. In buildroot wird so vieles gesetzt und ich hab wohl das richtige verpasst.
[20:15:56] <olistudent> er13: Richtig, wenn der gcc-final (stage 2) mit "—with-sysroot=/foo/bar" gebaut wird und "—prefix=/foo/". Dann sucht er die Header und Libs relativ zum aufgerufenen Binary. Und der ld bekommt "—sysroot=/foo/bar" übergeben und findet die Libs auch wenn sie nicht mit "-L /foo/bar/lib" übergeben werden.

Test-Case #1: Prüfen auf _MIPS_SZPTR → 32-bit?

[toolchain/build/gcc-4.4.4-uClibc-0.9.30.3/mipsel-linux-uclibc/usr/include/bits/wordsize.h]
#define __WORDSIZE	_MIPS_SZPTR
cd freetz-trunk
BASE_DIR=$(pwd)
PATH=$BASE_DIR/toolchain/target/bin:"$PATH"
mipsel-linux-uclibc-gcc -x c /dev/null -E -dD | grep SZPTR
Output: #define _MIPS_SZPTR 32

Test-Case #2: Host gcc benutzt Includes des Target mipsel-gcc?

cd /home/sd/pbuilder/freetz/freetz-trunk/source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4-target/gcc

gcc -c -DIN_GCC   -g -O2  -DGENERATOR_FILE -I. \
-Ibuild -I/home/sd/pbuilder/freetz/freetz-trunk/source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4/gcc \
-I/home/sd/pbuilder/freetz/freetz-trunk/source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4/gcc/build \
-I/home/sd/pbuilder/freetz/freetz-trunk/source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4/gcc/../include \
-I/home/sd/pbuilder/freetz/freetz-trunk/source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4/gcc/../libcpp/include \
-I/usr/include \
-I/home/sd/pbuilder/freetz/freetz-trunk/source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4/gcc/../libdecnumber \
-I/home/sd/pbuilder/freetz/freetz-trunk/source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4/gcc/../libdecnumber/dpd \
-I../libdecnumber \
-o build/genchecksum.o \
/home/sd/pbuilder/freetz/freetz-trunk/source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4/gcc/genchecksum.c

Ersetzt man "-I/home/sd/pbuilder/freetz/freetz-trunk/toolchain/build/gcc-4.4.4-uClibc-0.9.30.3/mipsel-linux-uclibc/usr/include" durch "I/usr/include" wird "build/genchecksum.o" gebaut.

Geändert vor 4 Jahren durch dileks

Added script to demonstrate which includes are used for build of gcc-target

Geändert vor 4 Jahren durch oliver

comment:37 Antworten: Geändert vor 4 Jahren durch oliver

Ich hab mal versucht die Änderungen der letzen 2 Jahren an den locales auf uClibc-0.9.29 backzuporten. Gebaut wird die uClibc, obs funktioniert? Keine Ahnung. Auf alle Fälle ist die Lib jetzt 220 KB (unkomprimiert) kleiner.

comment:38 als Antwort auf: ↑ 37 ; Antwort: Geändert vor 4 Jahren durch dileks

Replying to oliver:

Ich hab mal versucht die Änderungen der letzen 2 Jahren an den locales auf uClibc-0.9.29 backzuporten. Gebaut wird die uClibc, obs funktioniert? Keine Ahnung. Auf alle Fälle ist die Lib jetzt 220 KB (unkomprimiert) kleiner.

Kein Wunder, dass libc.so* jetzt kleiner wird, da nur noch EN + DE als locales ausgewählt wird. $UCLIBC_BUILD_MINIMAL_LOCALES="en_US de_DE"

Was ist mit $UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA? Wird das nicht mehr benötigt? Ist bei dir in toolchain/make/target/uclibc/Config.mod.0.9.29 rausgefallen.

Die Änderungen an Config.mod.0.9.29 könnte man auch in die Config.mods von 0.9.30.3 und 0.9.31 einfliessen lassen.

[toolchain/make/target/uclibc/uclibc.mk]:

  1. Verwendung der "pregenerated locale data" wird unterbunden (UCLIBC_SITE_LOCALE und UCLIBC_SOURCE_LOCALE)
  2. Der Copy-Befehl (wie von mir bereits angesprochen) ist kommentiert - danke.
  3. Auch wenns auskommentiert ist, bitte keine hardcodiertes Tarball-Name (kommt von er13).

# cp -dpf $(UCLIBC_LOCALE_DATA) $(UCLIBC_DIR)/extra/locale/uClibc-locale-20081111-32-el.tgz

  1. Gut! Unterscheidung via ifneq ($(FREETZ_TARGET_TOOLCHAIN_SYSROOT),y)
  2. Mir fehlt prinzipiell ein Kommentar bzgl. Kommentierung der Lines zwecks "pregenerated locale data" (*PREGENERATED_LOCALE_DATA*).
  3. Diese Änderungen sollten in einen separaten Patch.

comment:39 Antworten: Geändert vor 4 Jahren durch dileks

Leider bricht bei mir der Toolchain-Bau immer noch in der Phase gcc-target/.compiled ab.

Ich benutze ein Debian/sid 32-bit Linux-System und habe gestern auf meinem Rescue-System (ebenso 32-bit sid) nochmals gebaut, es bricht an der gleichen Stelle (s.w.o. Test-Cases).

Ich werde jetzt nochmal mit Fedora-13 bauen.

Damit ich hier nicht noch wahnsinnig werde:

  1. Mit welcher freetz-trunk svn-rev habt Ihr gebaut?
  2. Welche Kombination von gcc/uClibC für die Target Toolchain hab Ihr erfolgreich gebaut?
  3. Könntet Ihr Eure freetz-config hier beifügen?

Danke.

comment:40 als Antwort auf: ↑ 39 Geändert vor 4 Jahren durch dileks

Replying to dileks: …

  1. Mit welcher freetz-trunk svn-rev habt Ihr gebaut?
  2. Welche Kombination von gcc/uClibC für die Target Toolchain hab Ihr erfolgreich gebaut?
  3. Könntet Ihr Eure freetz-config hier beifügen?
  1. Welche Distribution (mit Release-Info) und Architektur (32/64-bit)?

Bsp: Ubuntu 10.04 LTS 32-bit

comment:41 Geändert vor 4 Jahren durch oliver

#850 ist eine Auswirkung, dass der Linker nicht in den mit "-L" übergebenen Pfaden sucht, sondern nur im sysroot. Trotzdem sollte es eigentlich funktionieren.

nächstes Ticket: #853

comment:42 als Antwort auf: ↑ 39 Geändert vor 4 Jahren durch dileks

Replying to dileks:

Leider bricht bei mir der Toolchain-Bau immer noch in der Phase gcc-target/.compiled ab.

Ich benutze ein Debian/sid 32-bit Linux-System und habe gestern auf meinem Rescue-System (ebenso 32-bit sid) nochmals gebaut, es bricht an der gleichen Stelle (s.w.o. Test-Cases).

Der Abbruch der Phase #3 (gcc-target) hat andere Gründe und nichts zu tun mit der verwendeten Distribution (bestätigt durch olistudent im IRC). Die Target Toolchain lässt sich bauen!

Z.Zt. sollte man deaktivieren (bisher kein FIX):
Menue → Advanced options → Compiler options

[ ] Build binutils and gcc for target (siehe P.S.)

"Build the binutils and gcc to run on the target" sprich gcc gebaut für Gebrauch auf der Box (was die wenigsten wirklich nutzen).

P.S.: Toolchains (X) Build toolchain (requires 4GB diskspace) muss aktiviert sein

comment:43 Geändert vor 4 Jahren durch er13

(In [5026]) gcc-target:

  • do not pass —with-gmp and —with-mpfr options to configure as this causes target-include-dirs to be added to host CPPFLAGS. As both libraries are installed in sysroot-directory gcc has no troubles finding them.
  • seems to fix gcc-target build failure (tested with uClibc-0.9.29 & gcc-4.3.5 only)
  • refs #842
  • use include-fixed both for gcc-4.3 and 4.4

comment:44 als Antwort auf: ↑ 38 Geändert vor 4 Jahren durch er13

Replying to dileks:

  1. Gut! Unterscheidung via ifneq ($(FREETZ_TARGET_TOOLCHAIN_SYSROOT),y)

gut hin oder her, alle in dem Patch enthaltenen Änderungen in uclibc.mk ab Zeile 92 (inklusive dieser Unterscheidung) sind Überreste meines target-toolchain-sysroot-Patches und sollten eher nicht committed werden…

Kannst Du jetzt gcc-target bauen? Bei mir funktioniert's jetzt mit gcc-4.3.5 und gcc-4.4.4. 4.2.4 müsste noch getestet werden…

@oliver: uclibc-0.9.30-patches lassen sich zwar anwenden aber mit fuzzes und offsets, falls Du Zeit hast, könntest Du dies bitte korrigieren.

comment:45 Geändert vor 4 Jahren durch oliver

Bei mir baut der gcc-target jetzt auch.

comment:46 Geändert vor 4 Jahren durch dileks

Ich konnte auch inzwischen gcc-target erfolgreich bauen:

  • freetz-trunk svn-rev5031
  • gcc-4.4.4-uClibc-0.9.30.3

Ein wenig Statistik:

  • Built-Time: 01h25m (11:16h-12:41h)
  • Disc-Usage: 3,6G + ca. 500M (dl dir, SymLink ausserhalb freetz-trunk dir)

Zusätzliche Informationen zur Build-Time:

  • FREETZ_VERBOSITY_LEVEL=2 und FREETZ_JLEVEL=5
  • CPU: Intel Core2Duo T7200, RAM: 2GByte

Ich habe aber noch einige Fragen zu er13's Patch in r5026 (später).

@oliver: Dass der gcc-target Build erfolgreich war ist unzureichend (Bitte genaue Informationen).

comment:47 Geändert vor 4 Jahren durch dileks

Nochmals der freundliche Hinweis alle neuen geistigen Ergüsse auch in die Toolchain-Wiki [1] einzupflegen, d.h.

  • Hinweis wichtige Patches
  • Schilderung von Problemen (mit Log-Files?)
  • Lösungsansatz erläutern (evtl. mit Use-Case, Test-Case)

In 4 Wochen wissen wir nicht mehr warum, weshalb, wieso?

[1] http://trac.freetz.org/wiki/toolchain

comment:48 Geändert vor 4 Jahren durch dileks

aus #fritzbox (heute):

[20:01:35] <dileX> $ du -s -h source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4-target
[20:01:35] <dileX> 330M source/toolchain/target/gcc-4.4.4-uClibc-0.9.30.3/gcc-4.4.4-target
[20:01:38] <dileX> $ du -s -h toolchain/build/gcc-4.4.4-uClibc-0.9.30.3/mipsel-linux-uclibc/target-utils
[20:01:38] <dileX> 83M toolchain/build/gcc-4.4.4-uClibc-0.9.30.3/mipsel-linux-uclibc/target-utils
[20:03:49] <dileX> olistudent: evtl. könnte man in den help-text von "[*] Build binutils and gcc for target" den hinweis eintragen, dass nochmals ca. 450M gebraucht wird. die 4GB grenze für die toolchain-bau ist dann gebrauchen hier (minimal-image)

comment:49 Geändert vor 4 Jahren durch cinereous

Ich würd sagen, "einfach" den Wert nach oben korrigieren und "ca. 4.5GB" draus machen.

comment:50 Geändert vor 4 Jahren durch er13

nur zur Info: habe alle Compiler-Versionen mit 0.9.29 getestet. Bei allen wird gcc-target ohne Probleme gebaut. Damit ist das Thema (gcc-target) für mich abgehakt.

comment:51 Geändert vor 4 Jahren durch cuma

Wenn ihr eine neue Download-Toolchain baut, wäre es dann vielleicht zusätzlich noch eine mit IPv6 Unterstützung möglich?

comment:52 Geändert vor 4 Jahren durch oliver

Wir haben nicht vor 6 Download-Toolchains zu machen. Wahrscheinlich gibt es 3 Versionen (mipsel 28, mipsel 29 und mips2) jeweweils mit IPv6. Wer das nicht haben will und die paar KB sparen will, der muss halt selbst bauen.

comment:53 Geändert vor 4 Jahren durch cuma

Hört sich gut an :-)

comment:54 Geändert vor 4 Jahren durch er13

Das muss ich zwar noch endgültig verifizieren, aber es sieht alles danach aus, dass das "mit nur 3" leider doch nicht geht. Ich habe mir einige Header-Dateien von uClibc angeschaut. Da gibt es an ein paar Stellen Struktur-Definitionen, die je nachdem, ob IPv6 aktiviert ist oder nicht, einige Felder enthalten oder eben nicht. Damit kann leider ein Binary, das gegen eine uClibc ohne IPv6 gelinkt wurde, nicht mit uClibc mit IPv6 Unterstützung verwendet werden (das Binary würde eine Struktur der kleineren Größe an uClibc weiterreichen, uClibc würde in der Annahme IPv6 zu unterstützen außerhalb des vom Binary allokierten Speicherbereichs greifen und damit irgendwas anderes überschreiben). Mit anderen Worten IPv6 ist leider eine die ABI-Kompatibilität verletztende Option.

Als Lösung würde ich vorschlagen, dass wir 4 Download-Toolchains anbieten:

  • 0.9.28(mipsel) - ohne IPv6, da es keine Box von AVM mit IPv6 von Haus aus gibt. Sollte irgendjemand seiner Box IPv6 beibringen wollen, soll er selbst bauen, aber halt auf eigene Gefahr und auch auf die Gefahr, dass es gar nicht funktioniert (nicht funktionieren würde es, wenn AVM's Binaries eine der anders definierten Strukturen nutzen würden)
  • 0.9.29(mipsel) - ohne IPv6 (diese soll für die meisten Boxen als default vorgewählt werden), mit IPv6 (default für die Boxen/Firmware, bei denen AVM IPv6 unterstützt)
  • 0.9.29(mips) - mit IPv6

p.s. und IPv6 gehört leider in target-uClibc-0.9.x-…-IPv6

comment:55 Geändert vor 4 Jahren durch er13

(In [5102]) apache:

  • workaround parallel build problems, refs #842

comment:56 Geändert vor 4 Jahren durch er13

(In [5167]) trickle:

  • workaround parallel build problems, refs #842

comment:57 Geändert vor 4 Jahren durch oliver

(In [5236]) * toolchain: Display warning if selected uClibc version is higher than 0.9.29

  • TODO: Remove original uClibc files from firmware if other version is selected
  • refs #842

comment:58 Geändert vor 4 Jahren durch oliver

(In [5244]) * Remove old uClibc (0.9.29) if a newer version is selected (refs #842)

  • AVM binaries relay on /lib/ld.so.1

comment:59 Geändert vor 4 Jahren durch er13

(In [5512]) target-tester:

  • add libc locale test, heavily based on the test supplied with uClibc
  • refs #842 (backport_uclibc_locale_updates.patch)

comment:60 als Antwort auf: ↑ 37 Geändert vor 4 Jahren durch er13

Replying to oliver:

Ich hab mal versucht die Änderungen der letzen 2 Jahren an den locales auf uClibc-0.9.29 backzuporten. Gebaut wird die uClibc, obs funktioniert? Keine Ahnung.

habe jetzt den Test aus uClibc (minimal angepasst) eingecheckt. Wenn das Output von dem Test mit der originalen Firmware und der modifizierten identisch ist, dann könnten wir denke ich davon ausgehen, dass es funktioniert (habe Deinen Patch noch nicht getestet). Zum Testen den folgenden Befehl auf der Box ausführen:
Edit (Aufruf korrigiert, man muss tst_nl_langinfo auch ein Mal parameterlos aufrufen)

( ./tst_nl_langinfo; for l in en_US en_US.UTF-8 de_DE de_DE.UTF-8; do ./tst_nl_langinfo $l; done ) > tst_nl_langinfo.output

comment:61 Geändert vor 4 Jahren durch oliver

Super! Danke dir.

comment:62 Geändert vor 4 Jahren durch er13

Habe uclibc mit Deinem Patch gebaut und die Firmware geflasht, die Box startet und bisher nichts auffälliges, die beiden Outputs stimmen jedoch nicht überein. Da taucht plötzlich Euro-Zeichen im englishen locale, als Fließkomma-Zeichen wird Komma statt Punkt verwendet und Wochentage bestehen nur aus 2 Zeichen statt 3 wie bisher. Bin am Verstehen, was da schief läuft.

Wenn ich es richtig verstehe, ist es nicht so trivial locale-Daten zu generieren: Endianess und Bittness des Build- und des Target-Systems müssen übereinstimmen. Eventuell wäre es besser, wenn wir die locale-Daten nicht bei jedem Build generieren, sondern einmal auf einem 32-Bit/LE-System pregenerieren und diese dann beim Build verwenden (bei 7390 muss es übrigens ein 32-Bit/BE-System sein).

NB: ich habe in dem Post oben den Aufruf von tst_nl_langinfo korrigiert, es muss auch ein Mal parameterlos aufgerufen werden.

comment:63 Geändert vor 4 Jahren durch oliver

Ich wüsste nicht was dagegen spricht, wenn wir uns zwei "precompiled" locale files bauen und die anstatt der vom uClibc Server nehmen. Steht das irgendwo, dass das so ist? Ich habe das nirgendwo gelesen als ich den Patch zusammengesucht habe.

edit: Steht tatsächlich in der README.

NOTE: While its possible to use this stuff for native != target arch,                                                           
you'll have to either write a converter to account for endianess and                                                            
struct padding issues, or run the mmap file generator on your target                                                            
arch. 

comment:64 Geändert vor 4 Jahren durch er13

Kurzer Statusbericht von mir. Auch die auf einem 32-Bit/LE-System generierten locale-Daten weichen von dem ab, was ich erwarten würde und was mit der nicht modifizierten uClibc von dem Test ausgegeben wird. Da muss mal wohl den Aufwand ins Verstehen von dem investieren, wie diese generiert werden und wahrscheinlich ein Paket analog target-tester erstellen, sodass das Ganze auf dem Zielsystem generiert wird (quasi gleich auch an 7390 gedacht)…

comment:65 Geändert vor 4 Jahren durch oliver

Ich hatte versucht im 32-Bit Chroot eine Toolchain mit "LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8" zu bauen. Hatte aber auch einige Abweichungen.

comment:66 Geändert vor 4 Jahren durch oliver

Okay, mein Output wird immer besser. :-) Die benötigten Locales müssen auf dem Host vorhanden sein, sonst nimmt er eine andere. Dann ist de_DE auf einmal Englisch und andersrum.

Wie meinst du jetzt, dass die Unterschiede (3 zu 2 Buchstaben zustande kommen)? Hängt das vielleicht von den locales auf meinem Host ab?

comment:67 Antwort: Geändert vor 4 Jahren durch er13

So wie es verstehe, werden die locales in der Tat aus der libc auf dem Host extrahiert (dies kann auch den Unterschied 3 vs. 2 Buchstaben erklären). Was ich nicht verstehe, wieso findet er dann de_DE nicht, glibc auf meinem Build-System enthält doch alle locales.

Kann man im Chroot/einer VM auch irgendein BE-System laufen lassen, um die locale-Daten für die 7390 zu erstellen?

comment:68 als Antwort auf: ↑ 67 ; Antwort: Geändert vor 4 Jahren durch oliver

Replying to er13:

Kann man im Chroot/einer VM auch irgendein BE-System laufen lassen, um die locale-Daten für die 7390 zu erstellen?

Wie wärs mit einem Debian Chroot auf einer 7390? :-)

comment:69 als Antwort auf: ↑ 68 Geändert vor 4 Jahren durch er13

Replying to oliver:

Wie wärs mit einem Debian Chroot auf einer 7390? :-)

naja, wenn ich schon auf Target ausführe, dann extrahiere ich doch einfach die Daten aus der uClibc der Target (hoffentlich hat AVM da nichts verbockt), dann sind mit deutlich größerer Wahrscheinlichkeit sich selbst identisch :-)

Jetzt mal ernst. Ich arbeite (zugegebenermaßen schon seit geschätzten drei Wochen) dadran, komme aber mangels Zeit nicht vorwärts. Wenn ich es richtig verstehe, muss die Häfte der Binaries, die zum Erstellen der locale-Daten ausgeführt werden müssen, auf dem Host und die Hälfte auf dem Target ausgeführt werden. Damit würde man einfach eine Untermenge von dem bekommen, was in uClibc auf der Box enthalten ist. Das Szenario, dass man die notwendigen Informationen aus der glibc extrahiert, ist wahrscheinlich nur dann von Bedeutung, wenn Du noch gar keine locale-Daten bzw. kein Target-System zur Verfügung hast.

Ich versuche mal dieses WE vorwärts zu kommen, i.e. tue in Bezug auf dieses Ticket erstmal nichts…

p.s. Alternative bestünde übrigens darin, freetz komplett auf der Box zu übersetzen ;-)

comment:70 Geändert vor 4 Jahren durch oliver

Bei mir hat das configure von Samba ca. 25 Minuten gedauert…

Geändert vor 4 Jahren durch er13

Geändert vor 4 Jahren durch er13

Achtung: noch ungetestet

comment:71 Geändert vor 4 Jahren durch er13

Zum locale-generator: habe mal den fürs Generieren der locale-Daten zuständigen Teil aus uClibc extrahiert (aus einem aktuellen snapshot). Extrahiert heißt, dass man das tarball entpacken und mit einfachem make-Aufruf die Daten generieren lassen kann - kein freetz notwendig.

Wie generieren: auf der Box gcc und make mit Hilfe von freetz installieren/einrichten. Tarball entpacken und

CC="gcc --sysroot PFAD_ZU_TARGET_UTILS" make tarball

aufrufen. Falls alles gut geht, wird ein Tarball mit dem Namen uClibc-locale-$(DATUM).tar.gz erzeugt, dieses ist beim Erstellen von uClibc statt uClibc-locale-030818.tgz zu verwenden.

p.s. Kleiner Kommentar zu dem Makefile vom generator (falls jemand mal reinschaut): ursprünglich habe ich es mir anders gedacht, daher tauchen da HOST_GCC bzw. TARGET_GCC auf… Kann sicherlich bereinigt werden, funktioniert momentan nur in dem "Alles auf dem HOST"-Modus (wobei als Host ein x-beliebiger Rechner inklusive Target verwendet werden kann).

comment:72 Antwort: Geändert vor 4 Jahren durch oliver

Und das Ergebnis hängt dann von der verwendeten "Locale Version" auf der Box ab? Also soll das mit der AVM uClibc durchgeführt werden?

comment:73 als Antwort auf: ↑ 72 ; Antwort: Geändert vor 4 Jahren durch er13

Replying to oliver:

Und das Ergebnis hängt dann von der verwendeten "Locale Version" auf der Box ab? Also soll das mit der AVM uClibc durchgeführt werden?

Ja, wie oben schon geschrieben, wenn wir eine echte Untermenge von den locale-Daten auf der Box haben wollen ohne irgendwelche Abweichungen, dann ist es am einfachsten, diese eben aus der uClibc auf der Box zu extrahieren. Hat auch den Vorteil, dass es dann auch für die (big-endian) 7390 funktioniert, muss allerdings auf einer ungefreetzten 7390 ausgeführt werden bzw. uclibc darf dabei nicht ersetzt werden.

Und soeben geflasht: juhu es funktioniert. Mit uClibc-locale-le-32-de_DE-en_US.tar.gz von oben bekomme ich genau den erwarteten Output ohne irgendwelche Abweichungen.

comment:74 als Antwort auf: ↑ 73 ; Antwort: Geändert vor 4 Jahren durch oliver

Replying to er13:

… allerdings auf einer ungefreetzten 7390 ausgeführt werden bzw. uclibc darf dabei nicht ersetzt werden.

Und wie genau stellen wir das an? Können wir etwas anbieten, das man auf der Box entpacken und ausführen kann.

comment:75 Geändert vor 4 Jahren durch er13

Also, der Gedanke war der, dass wir die locale-Daten einmal generieren und statt uClibc-locale-030818.tgz verwenden. Für die LE-Boxen habe ich schon diese generiert (uClibc-locale-le-32-de_DE-en_US.tar.gz). Für die 7390 muss irgendein Dev, der eine 7390 hat, diese mit Hilfe des locale-generators nach der oben beschriebenen Vorgehensweise generieren. Der User an sich muss nichts machen.

Das einzige Problem, das ich dabei sehe, ist, dass der User es gar nicht wählen kann, welche locales er haben möchte, das haben wir für ihn schon entschieden (de_DE, en_US). Das sehe ich aber nicht als all zu großes Problem… arbeite grad an dem Patch, wo man wählen kann, entweder alle Locales oder nur de_DE, en_US.

p.s. Dieses "locale-Daten generieren" so wie es momentan in uClibc umgesetzt ist, ist ein großer Hack. Der Aufwand es so zu richten, dass es auf jedem Build-System für jedes Target-System funktioniert, erscheint mir viel zu groß.

comment:76 als Antwort auf: ↑ 74 Geändert vor 4 Jahren durch er13

Replying to oliver:

Können wir etwas anbieten, das man auf der Box entpacken und ausführen kann.

Ja, target-utils + make + libraries(gmp, mpfr) + ein Script, das die Variablen wie PATH und LD_LIBRARY_PATH setzt.

comment:77 Geändert vor 4 Jahren durch er13

(In [5761]) uClibc:

  • Provide an option which allows to control a set of locales included in uClibc. It is now possible to build it with a reduced set of locales (de_DE* & en_US* only). Saves about 235KB in the image and at run-time.
  • refs #842

Note: The required uClibc-locale-le-32-de_DE-en_US.tar.gz might not be yet available on all mirrors, please download it manually from http://trac.freetz.org/attachment/ticket/842/uClibc-locale-le-32-de_DE-en_US.tar.gz

comment:78 Geändert vor 4 Jahren durch oliver

  • Zusammenfassung von FREETZ_JLEVEL > 3 breaks toolchain compilation nach toolchain updates (binutils, gcc, uclibc,...) geändert

comment:79 Geändert vor 4 Jahren durch er13

(In [5815]) uClibc:

  • fix uClibc versions 0.9.3x ignore pregenerated locale data files (they were always overwritten/regenerated)
  • disable UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA symbol as we download it ourselves
  • refs #842

Geändert vor 4 Jahren durch oliver

Build uClibc-0.9.28 toolchain with gcc-4.4.4 (not working yet)

comment:80 Geändert vor 4 Jahren durch er13

  • Status von new nach assigned geändert
  • Verantwortlicher auf er13, oliver gesetzt

comment:81 Geändert vor 4 Jahren durch er13

(In [5898]) Automate download-toolchain creation, refs #842

comment:82 Geändert vor 4 Jahren durch er13

habe beim r5910 das refs vergessen

comment:83 Geändert vor 4 Jahren durch oliver

Merkt doch keiner :-)

(In [5910]) toolchain:

fix host ldd & ldconfig are always linked dynamically regardless of FREETZ_STATIC_TOOLCHAIN value

comment:84 Geändert vor 4 Jahren durch oliver

Das betrifft nur Binaries? Libs müssen immer PIC code sein oder?

comment:85 Geändert vor 4 Jahren durch er13

Ja, Libs müssen immer PIC sein. Binaries dürfen beides sein. Non-PIC Variante ist aber kleiner und schneller - s. hier

comment:86 Geändert vor 4 Jahren durch er13

@oliver: Habe jetzt alles mit dem non-PIC-Patch übersetzt. Die meisten Binaries sind in der Tat deutlich kleiner: mein Image ist komprimiert 80KB kleiner geworden, externalisierte Binaries sind in der Summe über 3MB kleiner. Es gibt aber auch Ausnahmen, samba ist z.B. nicht kleiner geworden (eventuell setzen die -fPIC irgendwo, habe noch nicht nachgeschaut).

Was ich noch nicht gemacht habe: ich habe das Image noch nicht geflasht. Grund: die erstellten Binaries sind mit der (ohne non-PIC patch erstellten) uClibc nicht kompatibel und laufen schlicht und ergreifend nicht (irgendwas unknown relocation type). Da meine Testbox gleichzeitig meine Produktivbox ist, wollte ich Dich fragen, ob Du den Smoke-Test nicht übernehmen könntest (habe keine Zeit für recover-Spielchen).

comment:87 Geändert vor 4 Jahren durch oliver

Hast du das FPIC in make/Makefile.in auskommentiert? Danach kommt es bei mir zu Problemen mit polarssl, weil -fPIC nicht mehr gesetzt ist.

make[1]: Betrete Verzeichnis '/home/oliver/fritzbox/freetz/trunk_i386/source/target-mipsel_uClibc-0.9.31/polarssl-0.14.0/library'
  LD    libpolarssl.so.0.14.0
/home/oliver/fritzbox/freetz/trunk_i386/toolchain/build/mipsel_gcc-4.4.4-uClibc-0.9.31/bin/../lib/gcc/mipsel-linux-uclibc/4.4.4/../../../../mipsel-linux-uclibc/bin/ld: aes.o: relocation R_MIPS_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
aes.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libpolarssl.so.0.14.0] Fehler 1
make[1]: Verlasse Verzeichnis '/home/oliver/fritzbox/freetz/trunk_i386/source/target-mipsel_uClibc-0.9.31/polarssl-0.14.0/library'

ERROR: Build failed.
make: *** [source/target-mipsel_uClibc-0.9.31/polarssl-0.14.0/library/libpolarssl.so.0.14.0] Fehler 1

Wir sollten dann die -fPIC Flags bei den Daemons entfernen? Und für die Libraries gesetzt lassen. Was ist der Unterschied zwischen "-fPIC" und "-fpic"?

edit: Einige Libs sind dadurch größer geworden?

  • libpopt, libpng, libart_lgpl, libncurses, libgd

comment:88 Geändert vor 4 Jahren durch er13

Nein, ich habe -fPIC nicht auskommentiert, aber nur weil ich es vergessen habe. Es gehört raus - es ist die Aufgabe der Library -fPIC zu setzen und nicht von uns in den default CFLAGS. D.h. polarssl und alles, was sich sonst beschwert, müssen gepatcht werden, s. auch hier

-fPIC vs -fpic: müsste jetzt auch nachlesen, worin sich diese genau unterscheiden. Aber soweit ich mich erinnern kann, ist der Unterschied nur eine andere Implementierung, das gelöste Problem und das Prinzip sind dieselben. Und -fPIC, wenn ich mich richtig erinnere, ist vorzuziehen.

comment:89 Geändert vor 4 Jahren durch oliver

  • make/samba/samba.mk

     
    100100       for target in headers all; do \ 
    101101       $(SUBMAKE) -C $(SAMBA_DIR)/source \ 
    102102               RANLIB="$(TARGET_RANLIB)" \ 
     103               PICFLAG="" \ 
    103104               $$target; \ 
    104105       done 

Macht das Binary um 300kb kleiner.

comment:90 Geändert vor 4 Jahren durch er13

FYI: GCC 4.4.5 has been released

comment:91 Geändert vor 4 Jahren durch oliver

(In [5922]) * Update gcc-4.4.4 version to gcc-4.4.5

comment:92 Geändert vor 4 Jahren durch oliver

(In [5925]) * target-toolchain: Build non-pic code with gcc-4.4.5 (refs #842)

comment:93 Geändert vor 4 Jahren durch er13

(In [5951]) toolchain:

  • build uClibc++ as early as possible to avoid all kind of errors (e.g. config.cache messed up by libgmp & libmpfr because they compiled before uClibc++). uClibc++ is actually a part of toolchain.
  • refs #842

comment:94 Geändert vor 4 Jahren durch er13

(In [5960]) toolchain:

  • disable mips-plt for all uClibc versions except for 0.9.31 (0.9.29 definitely doesn't work, 0.9.30.3 to be tested)
  • refs #842

A BIG FAT WARNING for all those out there who

  • use self-built toolchain
  • use gcc-4.4.5
  • use uClibc-0.9.29 (0.9.30.3 is, as stated above, not tested yet)
  • haven't flashed the image yet

do not flash it or you will have to recover your box. Do recompile everything (toolchain and all packages) before flashing again.

comment:95 Geändert vor 4 Jahren durch oliver

uClibc-0.9.30.3 funktioniert bei mir mit mips-plt

comment:96 Antwort: Geändert vor 4 Jahren durch oliver

Dieser commit/diff ohne die Änderung in dl-hash.c sollte das Problem lösen: http://git.uclibc.org/uClibc/commit/?id=7f07b8deffa7eaea0cbab9e84503b7644a6b6f8e

comment:97 Antwort: Geändert vor 4 Jahren durch oliver

(In [5967]) * toolchain: Add "—disable-tls" to gcc switches (see http://sourceware.org/ml/crossgcc/2010-02/msg00081.html)

comment:98 als Antwort auf: ↑ 96 ; Antwort: Geändert vor 4 Jahren durch er13

Replying to oliver:

Dieser commit/diff ohne die Änderung in dl-hash.c sollte das Problem lösen

warum ohne dl-hash.c?

comment:99 als Antwort auf: ↑ 97 Geändert vor 4 Jahren durch er13

Replying to oliver:

(In [5967]) * toolchain: Add "—disable-tls" to gcc switches

Hmm, komisch, an der gleichen Stelle, wo es um die Relocations ging, war in 0.9.31 zu sehen, dass TLS angeblich unterstüzt wird. Wobei, dass es nur mit NPTL geht, klingt auch irgendwie plausibel. Wann tritt das Problem denn auf? Wenn man aus einem C++-Programm Threads erzeugt? nur mit libstdc++? oder auch mit uClibc++?

comment:100 Geändert vor 4 Jahren durch oliver

Ich hatte einen Fehler bei espeak (hatte ich dir glaube ich per PN geschickt). Hier wurde die libstdc statisch gelinkt. Mit "—disable-tls" funktionierte es dann. Wobei ich später die libstdc aus den Libs entfernt habe.

comment:101 als Antwort auf: ↑ 98 ; Antwort: Geändert vor 4 Jahren durch oliver

Replying to er13:

Replying to oliver:

Dieser commit/diff ohne die Änderung in dl-hash.c sollte das Problem lösen

warum ohne dl-hash.c?

Weil die Änderung in dl-hash ohne http://git.uclibc.org/uClibc/commit/?id=6630516b0a000e0ac9769eceda72881f788b23b0 nicht nötig ist?

comment:102 als Antwort auf: ↑ 101 Geändert vor 4 Jahren durch er13

Replying to oliver:

warum ohne dl-hash.c?

Weil die Änderung in dl-hash ohne nicht nötig ist?

also, ich meine doch, der hinzugefügte Code ist nicht mit #ifdef __LDSO_GNU_HASH_SUPPORT__ umrandet, von daher hat es auch nichts mit .gnu.hash-Sektion zu tun, sondern mit non-pic support. Er liest sich auch so…

Edit: Du hast Recht, der dl-hash.c-Teil ist nicht notwendig, aber nicht wegen GNU_HASH_SUPPORT, sondern weil gar keine hash-Sektionen unterstützt werden.

Geändert vor 4 Jahren durch er13

noch ungetestet

comment:103 Geändert vor 4 Jahren durch er13

(In [5972]) toolchain/uClibc:

comment:104 Geändert vor 4 Jahren durch oliver

Sollte nach r5951 nicht das uclibcxx in Zeile 24 entfernt werden? Zumal da auch die Abfrag nach FREETZ_TARGET_GXX fehlt.

comment:105 Geändert vor 4 Jahren durch er13

ja, habe ich übersehen

comment:106 Geändert vor 4 Jahren durch er13

(In [5976]) toolchain:

  • remove unnecessary/duplicated dependency, missed in r5951, refs #842

comment:107 Geändert vor 4 Jahren durch er13

(In [6025]) * fix gcc-4.2.4 silently ignores -pthread flag when linking shared libraries

  • refs #1071, it actually fixes it for self-built toolchain
  • refs #842

comment:109 Geändert vor 4 Jahren durch oliver

locale extractor auf 7320:

gcc --sysroot /var/media/ftp/Kingston-DataTraveler2-0-12/target -o bin/gen_locale  -Iinclude/bits -Igenerated/ -D_GNU_SOURCE -D__UCLIBC_GEN_LOCALE  gen_locale.c
In file included from gen_locale.c:13:
generated/c8tables.h:84:1: warning: "__LOCALE_DATA_CODESET_LIST" redefined
generated/c8tables.h:4:1: warning: this is the location of the previous definition
gen_locale.c:1083:2: warning: #warning fix the char entries for monetary... target signedness of char may be different!
bin/gen_locale -v -o generated/locale_tables.h locales.txt
UTF-8 locales are enabled
8-BIT locales are enabled
Error: unsupported codeset ISO-8859-1
make: *** [generated/locale_tables.h] Error 1

comment:110 Geändert vor 4 Jahren durch oliver

Ich hab hier ein Problem mit Kernel 2.6.28 (7320). Die MIPS spezifischen Includes wurden nach arch/mips/include verschoben. Daher werden sie von uclibc nicht mehr gefunden.

  • toolchain/make/target/uclibc/uclibc.mk

     
    9696    if [ ! -f $(2)/usr/include/linux/version.h ] ; then \ 
    9797        cp -pLR $(1)/{asm,asm-generic,linux} $(2)/usr/include/; \ 
    9898    fi; 
     99    if [ -d $(1)/../arch/mips/include/asm ]; then \ 
     100        cp -pLR $(1)/../arch/mips/include/asm $(2)/usr/include/; \ 
     101    fi 
    99102endef 
    100103 
    101104$(UCLIBC_DIR)/.configured: $(UCLIBC_DIR)/.config 

Die zusätzlichen Header müssten also auch in das uClibc_devel Verzeichnis kopiert werden. Und die Konfigoption KERNEL_HEADERS der uClibc sollte dann auf dieses Verzeichnis zeigen? Oder wie ist das gedacht?

comment:111 Geändert vor 4 Jahren durch er13

So wie jetzt geht es befürchte ich nicht mehr. Die Kollegen von openwrt installieren die Headers in ein Extra-Verzeichnis (kopieren bei Bedarf das verschobene Unterverzeichnis) und referenzieren dann dieses neue Verzeichnis.

comment:112 Geändert vor 4 Jahren durch oliver

Ich hab mal ein ersten Vorschlag angehängt. Die Kernel Header werden im Fall von "build toolchain" in ein extra Verzeichnis installiert und von dort in die TARGET_TOOLCHAIN_STAGING_DIR. Für uClibc-0.9.30 funktioniert das. Die anderen hab ich noch nicht getestet. Muss an den Paketen, die die Variable "KERNEL_HEADERS_DIR" verwenden noch was angepasst werden?

edit: 2.6.13 hat natürlich kein headers_install target…

comment:113 Geändert vor 4 Jahren durch oliver

http://freetz.magenbrot.net/uClibc-locale-be-32-de_DE-en_US.tar.gz

Das Archiv ist mit einer 7320 erstellt auf der eine selbst gebaute uClibc-0.9.30.3 läuft. Trotzdem stimmten die 2 Outputs vom language tester überein. Ist das möglich? Beim Build wurde das Archiv vom uClibc Server (uClibc-locale-030818.tgz) genommen.

comment:114 Geändert vor 4 Jahren durch er13

Ich kann die Datei nicht downloaden

--2010-10-25 23:10:24--  ftp://freetz.magenbrot.net/uClibc-locale-be-32-de_DE-en_US.tar.gz
Resolving freetz.magenbrot.net... x.x.x.x
Connecting to freetz.magenbrot.net|x.x.x.x|:21... connected.
Logging in as anonymous ... 
The server refuses login.
Retrying.

könntet Du sie bitte hier anhängen. Ich will sie mit der für little-endian vergleichen.

AVM scheint die uClibc für die 7320 mit little-endian locales gebaut zu haben. In der fritzbox7320-source-files-04.86.tar.gz/opensrc/GPL-gcc.tar.gz/dl liegt zwar eine Datei, die uClibc-locale-20081111-32-eb.tgz heißt. Sie ist aber identisch zu uClibc-locale-030818.tgz (little-endian). Das lässt stark vermuten, dass es in Wirklichkeit keinen Unterschied zwischen den locale-Daten für LE und BE gibt, auch wenn die uClibc-Entwickler was anderes behaupten…

comment:115 Geändert vor 4 Jahren durch oliver

In den Dateien sind schon Unterschiede. Aber schaus dir am Besten selbst an. Ich hab die URL korrigiert.

comment:116 Geändert vor 4 Jahren durch er13

Könntest Du bitte alle Dateien aus dem generated Verzeichnis anhängen, es fehlen noch locale_tables.h und locale_collate.h

Geändert vor 4 Jahren durch oliver

Geändert vor 4 Jahren durch oliver

Diff des AVM uClibc-0.9.29 Source gegen Original (Source 7270 04.86)

comment:117 Geändert vor 4 Jahren durch er13

Zu dem uClibc-avm.diff:

Änderungen in include/avm_wrap.h, include/string.h, include/time.h, ldso/libdl/libdl.c, libc/sysdeps/linux/mips/crt1.S, libc/sysdeps/linux/mips/crti.S, libc/sysdeps/linux/mips/crtn.S, libpthread/linuxthreads/pt-machine.c, libpthread/linuxthreads.old/ptfork.c sind alles Schmarrn, raus mit diesen.

libc/inet/resolv.c bis auf HOST_NOT_FOUND ist irgendein Testcode, den wir ebenso nicht brauchen. HOST_NOT_FOUND haben wir als separaten Patch.

Änderungen in libc/string/mips/memcpy.S, libc/string/mips/memset.S ist ein gcc-3.4.x Workaround, brauchen wir nicht, da wir uClibc mit gcc-4.x übersetzen.

Änderungen in libc/sysdeps/linux/mips/bits/socket.h werden gebraucht, würde ich aber als separaten Patch einchecken.

libpthread/linuxthreads/sysdeps/arm/pt-machine.h, libpthread/linuxthreads.old/sysdeps/arm/pt-machine.h - muss ich noch verstehen, sind aber beide für ARM, gibt es schon eine FritzBox mit ARM-Prozessor? 7320?

Ich teste es mal, wenn es stimmt, was ich da sage, dann schmeisse ich auch die aktuell eingecheckte Version von diesem Patch raus.

comment:118 Geändert vor 4 Jahren durch oliver

Die 7320 ist auch mips (be). Diese verwendet ja zudem uClibc-0.9.30.

comment:119 Geändert vor 4 Jahren durch er13

In ([6102]) uClibc:

  • revise avm-patch: remove parts we don't need, move part of it to 170-NTH_socket_h.patch (it's actually an upstream patch)
  • fix offsets in other patches

comment:120 Geändert vor 4 Jahren durch er13

(In [6103]) uClibc:

  • fix progname is NULL when referenced from nonpic binaries
  • refs #842

comment:121 Geändert vor 4 Jahren durch er13

(In [6104]) uClibc:

  • fix assembler warnings (upstream backport)
  • refs #842

comment:122 Geändert vor 4 Jahren durch er13

(In [6105]) uClibc:

  • fix pipe function doesn't pass return value to c-function
  • it was fixed upstream in the same commit as the same syscall bug, I don't understand why we had the syscall-fix, but not the pipe one
  • refs #842

comment:123 Geändert vor 4 Jahren durch er13

(In [6106]) binutils for target:

  • bump version to 2.20.51.0.12
  • refs #842

comment:124 Geändert vor 4 Jahren durch er13

(In [6108]) toolchain:

  • always build toolchain with c++ support. we don't actually support a c-only toolchain and I don't see any reason to put effort into it.
  • refs #842

comment:125 Geändert vor 4 Jahren durch oliver

Zu comment:110: Wie wollen wir denn mit den Kernel-Headern verfahren?

Problem: Kernel 2.6.28 (7320) hat die mips spezifischen Kernel Header nicht mehr unter include/. Daher werden sie ohne Änderungen nicht in das uclibc_devel Verzeichnis kopiert.

Mögliche Lösung: Man kann die Kernel Header mit make headers_install installieren. Patch hängt oben an. Leider funktioniert das für 2.6.13 nicht.

Das headers_install Target ist wohl nicht so einfach backzuporten. Hier fehlen die Kbuild Dateien im Kernel Tree. Scheint wohl also auf Ausnahmen (ifeq…) rauszulaufen. Die Frage ist nur wofür die Ausnahme gemacht wird? Für 2.6.13 oder für 2.6.28?

Hat jemand Vorschläge?

comment:126 Geändert vor 4 Jahren durch oliver

(In [6128]) * uClibc-0.9.29: Disable LDSO_CACHE_SUPPORT (we don't use /etc/ld-uClibc.so.cache)

comment:127 Geändert vor 4 Jahren durch er13

(In [6165]) uClibc-0.9.28:

  • backport move_dl_iterate_phdr-patch
  • fixes "libgcc_s.so: undefined reference to `dl_iterate_phdr'"-problem and all other problems it causes (like broken c++-compiler, broken libtool-host package, all packages with replaced libtool don't compile and so on)
  • refs #842
  • only rudimentary tested on FritzBox Fon WLAN (08.04.34), more feedback, especially if some packages stop working after this patch, is welcome

comment:128 Geändert vor 4 Jahren durch er13

(In [6170]) uClibc-0.9.28:

  • add gcc-4.4.5 support (experimental)
  • only rudimentary tested on FritzBox Fon WLAN (08.04.34)
  • refs #842

comment:129 Antwort: Geändert vor 4 Jahren durch er13

@Oliver: mit gcc-4.4.5 sind alle Binaries und die meisten Libraries deutlich kleiner. Die einzige Ausnahme, die leider alles zunichte macht, ist libgcc_s.so - diese ist im Vergleich zu gcc-4.2.4 110KB größer :-(

comment:130 Antwort: Geändert vor 4 Jahren durch oliver

Das ist mir auch schon aufgefallen. Ich hab auch schon probiert wie wir das lösen könnten → statische libgcc. Dazu bräuchten wir bei der Target Toolchain einen Durchgang mehr. Der erste bleibt gleich. Im zweiten wird mit —enable-shared gebaut (libgcc_s und libstdc++). Und im dritten Durchgang dann nochmal mit —disable-shared. Dabei gibts noch ein kleines Problem mit der libsupc++, das aber leicht zu lösen sein sollte. Ich wäre aber dafür das auf später zu verschieben.

comment:131 als Antwort auf: ↑ 130 ; Antwort: Geändert vor 4 Jahren durch er13

Replying to oliver:

lösen könnten → statische libgcc.

Ich glaube kaum, dass das das Problem lösen würde. Du würdest zwar nicht die ganze libgcc_s, sondern nur Teile davon, aber in alle möglichen Libraries/Binaries linken. Irgendwann mal (und ich vermute recht schnell) werden diese Teile in der Summe größer sein als die libgcc_s.so selbst. Außerdem ist ein Haufen AVM's Libraries/Binaries dynamisch gegen libgcc_s.so gelinkt. D.h. Du wirst sie nicht wirklich los werden können.

comment:132 als Antwort auf: ↑ 129 Geändert vor 4 Jahren durch ralf

Replying to er13:

diese ist im Vergleich zu gcc-4.2.4 110KB größer :-(

Wie wäre es damit:

$ size toolchain/build/gcc-4.4.5-uClibc-0.9.29/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/lib/libgcc_s.so.1
   text    data     bss     dec     hex filename
  79785    2272     544   82601   142a9 toolchain/build/gcc-4.4.5-uClibc-0.9.29/mipsel-linux-uclibc/usr/mipsel-linux-uclibc/lib/libgcc_s.so.1
Index: toolchain/make/target/gcc/gcc.mk
===================================================================
--- toolchain/make/target/gcc/gcc.mk    (Revision 6162)
+++ toolchain/make/target/gcc/gcc.mk    (Arbeitskopie)
@@ -129,6 +129,7 @@
                --disable-libmudflap \
                --disable-multilib \
                --disable-tls \
+               --disable-fixed-point \
                $(GCC_DECIMAL_FLOAT) \
                $(GCC_WITH_HOST_GMP) \
                $(GCC_WITH_HOST_MPFR) \
@@ -195,6 +196,7 @@
                --disable-multilib \
                --disable-libmudflap \
                --disable-tls \
+               --disable-fixed-point \
                $(GCC_WITH_HOST_GMP) \
                $(GCC_WITH_HOST_MPFR) \
                $(GCC_SHARED_LIBGCC) \

comment:133 Antwort: Geändert vor 4 Jahren durch er13

Hmm, haben wir irgendwelche Packages (math/graphic/audio/multimedia), die fixed-point arithmetic nutzen? Wieviel würden wir denn dadurch sparen und haben wir dadurch gewaltige Performance-Verluste zu erwarten?

Der Größernunterschied zwischen 4.2.4 und 4.4.5 kommt außerdem durch etwas anderes zustande, denn bei beiden compiler-Versionen ist fixed-point arithmetic enabled:

checking whether fixed-point is supported... yes

comment:134 als Antwort auf: ↑ 133 ; Antwort: Geändert vor 4 Jahren durch ralf

Replying to er13:

Ich gehe mal davon aus, daß wir keine Pakete haben, die fixed-point nutzen. Ansonsten bräuchte man auch nicht die Funktion im Compiler auszuschalten, es war nur die einfachste Möglichkeit, die Funktionen aus der Library raus zu halten. Ich würde es so einmal ausprobieren, so wie es aussieht, sparen wir damit 100k.

Bei mir ist die neue Library nicht viel größer als die alten.

   text    data     bss     dec     hex filename
 152092     680     144  152916   25554 gcc-4.3.3/libgcc_s.so.1
 168147    2388     544  171079   29c47 gcc-4.3.5/libgcc_s.so.1
 175964    2564     544  179072   2bb80 gcc-4.4.5/libgcc_s.so.1
  79785    2272     544   82601   142a9 gcc-4.4.5-ohne-fix/libgcc_s.so.1

Neu gegenüber 4.3.5 sind folgende Funktionen:

+ T __mips16_adddf3
+ T __mips16_addsf3
+ T __mips16_call_stub_1
+ T __mips16_call_stub_10
+ T __mips16_call_stub_2
+ T __mips16_call_stub_5
+ T __mips16_call_stub_6
+ T __mips16_call_stub_9
+ T __mips16_call_stub_dc_0
+ T __mips16_call_stub_dc_1
+ T __mips16_call_stub_dc_10
+ T __mips16_call_stub_dc_2
+ T __mips16_call_stub_dc_5
+ T __mips16_call_stub_dc_6
+ T __mips16_call_stub_dc_9
+ T __mips16_call_stub_df_0
+ T __mips16_call_stub_df_1
+ T __mips16_call_stub_df_10
+ T __mips16_call_stub_df_2
+ T __mips16_call_stub_df_5
+ T __mips16_call_stub_df_6
+ T __mips16_call_stub_df_9
+ T __mips16_call_stub_sc_0
+ T __mips16_call_stub_sc_1
+ T __mips16_call_stub_sc_10
+ T __mips16_call_stub_sc_2
+ T __mips16_call_stub_sc_5
+ T __mips16_call_stub_sc_6
+ T __mips16_call_stub_sc_9
+ T __mips16_call_stub_sf_0
+ T __mips16_call_stub_sf_1
+ T __mips16_call_stub_sf_10
+ T __mips16_call_stub_sf_2
+ T __mips16_call_stub_sf_5
+ T __mips16_call_stub_sf_6
+ T __mips16_call_stub_sf_9
+ T __mips16_divdf3
+ T __mips16_divsf3
+ T __mips16_eqdf2
+ T __mips16_eqsf2
+ T __mips16_extendsfdf2
+ T __mips16_fix_truncdfsi
+ T __mips16_fix_truncsfsi
+ T __mips16_floatsidf
+ T __mips16_floatsisf
+ T __mips16_floatunsidf
+ T __mips16_floatunsisf
+ T __mips16_gedf2
+ T __mips16_gesf2
+ T __mips16_gtdf2
+ T __mips16_gtsf2
+ T __mips16_ledf2
+ T __mips16_lesf2
+ T __mips16_ltdf2
+ T __mips16_ltsf2
+ T __mips16_muldf3
+ T __mips16_mulsf3
+ T __mips16_nedf2
+ T __mips16_nesf2
+ T __mips16_ret_dc
+ T __mips16_ret_df
+ T __mips16_ret_sc
+ T __mips16_ret_sf
+ T __mips16_subdf3
+ T __mips16_subsf3
+ T __mips16_truncdfsf2

+ T __sync_add_and_fetch_1
+ T __sync_add_and_fetch_2
+ T __sync_add_and_fetch_4
+ T __sync_and_and_fetch_1
+ T __sync_and_and_fetch_2
+ T __sync_and_and_fetch_4
+ T __sync_bool_compare_and_swap_1
+ T __sync_bool_compare_and_swap_2
+ T __sync_bool_compare_and_swap_4
+ T __sync_fetch_and_add_1
+ T __sync_fetch_and_add_2
+ T __sync_fetch_and_add_4
+ T __sync_fetch_and_and_1
+ T __sync_fetch_and_and_2
+ T __sync_fetch_and_and_4
+ T __sync_fetch_and_nand_1
+ T __sync_fetch_and_nand_2
+ T __sync_fetch_and_nand_4
+ T __sync_fetch_and_or_1
+ T __sync_fetch_and_or_2
+ T __sync_fetch_and_or_4
+ T __sync_fetch_and_sub_1
+ T __sync_fetch_and_sub_2
+ T __sync_fetch_and_sub_4
+ T __sync_fetch_and_xor_1
+ T __sync_fetch_and_xor_2
+ T __sync_fetch_and_xor_4
+ T __sync_lock_test_and_set_1
+ T __sync_lock_test_and_set_2
+ T __sync_lock_test_and_set_4
+ T __sync_nand_and_fetch_1
+ T __sync_nand_and_fetch_2
+ T __sync_nand_and_fetch_4
+ T __sync_or_and_fetch_1
+ T __sync_or_and_fetch_2
+ T __sync_or_and_fetch_4
+ T __sync_sub_and_fetch_1
+ T __sync_sub_and_fetch_2
+ T __sync_sub_and_fetch_4
+ T __sync_synchronize
+ T __sync_val_compare_and_swap_1
+ T __sync_val_compare_and_swap_2
+ T __sync_val_compare_and_swap_4
+ T __sync_xor_and_fetch_1
+ T __sync_xor_and_fetch_2
+ T __sync_xor_and_fetch_4

comment:135 als Antwort auf: ↑ 131 ; Antworten: Geändert vor 4 Jahren durch oliver

Replying to er13:

Ich glaube kaum, dass das das Problem lösen würde. Du würdest zwar nicht die ganze libgcc_s, sondern nur Teile davon, aber in alle möglichen Libraries/Binaries linken.

Ich konnte bei ersten Tests kein Programm ausmachen, das dadurch wirklich gewachsen wäre. Die meisten Binarys waren 100 Bytes kleiner, einige auch mehrere Kilobyte.

Die Ersparnis wäre natürlich nur, dass wir die libgcc_s nicht ersetzen müssten.

comment:136 als Antwort auf: ↑ 135 Geändert vor 4 Jahren durch ralf

Replying to oliver:

Die Ersparnis wäre natürlich nur, dass wir die libgcc_s nicht ersetzen müssten.

Mit der obigen Änderung ist der Größenunterschied nicht mehr sonderlich groß. Man könnte auch schauen, ob noch weitere Funktionen nicht benötigt werden, wie diese neu dazu gekommenen Funktionen.

Wenn andererseits die Programme tatsächlich kleiner sind, kann man die auch statisch linken. Es wäre noch interessant, welche Funktionen in diesem Fall aufgerufen werden, und warum die Programme mit statischer libgcc kleiner sind.

Eine andere Frage ist, wie es mit den Libraries aussieht.

comment:137 als Antwort auf: ↑ 135 Geändert vor 4 Jahren durch ralf

Replying to oliver:

Ich konnte bei ersten Tests kein Programm ausmachen, das dadurch wirklich gewachsen wäre. Die meisten Binarys waren 100 Bytes kleiner, einige auch mehrere Kilobyte.

Bei mir sieht es anders aus, Beispiel openntpd mit -shared-libgcc, -static-libgcc und default:

$ mipsel-linux-uclibc-gcc -o ntpd ntpd.o buffer.o log.o imsg.o ntp.o ntp_msg.o config.o server.o client.o util.o y.tab.o openbsd-compat/libopenbsd-compat.a -shared-libgcc
$ size ntpd
   text    data     bss     dec     hex filename
  36988     568    2456   40012    9c4c ntpd
$ mipsel-linux-uclibc-gcc -o ntpd ntpd.o buffer.o log.o imsg.o ntp.o ntp_msg.o config.o server.o client.o util.o y.tab.o openbsd-compat/libopenbsd-compat.a -static-libgcc
$ size ntpd
   text    data     bss     dec     hex filename
  42589     576    2456   45621    b235 ntpd
$ mipsel-linux-uclibc-gcc -o ntpd ntpd.o buffer.o log.o imsg.o ntp.o ntp_msg.o config.o server.o client.o util.o y.tab.o openbsd-compat/libopenbsd-compat.a
$ size ntpd                    text    data     bss     dec     hex filename
  43081     584    2456   46121    b429 ntpd

Standard scheint zu sein, die libgcc statisch dazu zu linken und dann noch einen NEEDED Eintrag für libgcc_s zu setzen.

Ein grep auf libgcc_s in 29.04.80 zeigt, daß libgcc_s zwar vorhanden ist, aber überhaupt nicht verwendet wird. Die 54.04.86 dagegen verwendet die Library fast überall.

comment:138 als Antwort auf: ↑ 134 Geändert vor 4 Jahren durch er13

Replying to ralf:

so wie es aussieht, sparen wir damit 100k.

Sieht in der Tat so aus - 100KB ohne, dass sich irgendwas nicht übersetzen lässt… Bin dafür fixed-point support zu disablen und die Spielchen static- vs. shared-libgcc auf später zu verschieben. AVM's Binaries könnte man eventuell mit mklibs von libgcc_s wieder befreien.

Nachdem libgcc_s dank Ralf so schnell wieder klein geworden ist, ist es aus meiner Sicht einer Überlegung wert, den gcc-4.4.5 auch bei uClibc-0.9.28 als default zu verwenden.

comment:139 Geändert vor 4 Jahren durch ralf

(In [6177]) * GCC: disable fixed-point, removes some unused functions from libgcc_s

comment:140 Antwort: Geändert vor 4 Jahren durch oliver

Mag mir mal bitte noch jemand erklären was es mit dem statischen Linken und dem NEEDED Eintrag auf sich hat? Warum wird die libgcc nicht standardmäßig "shared" gelinkt? aus dumpspecs:

*libgcc:
%{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed -lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc}}}}

libgcc? libgcc_s? libgcc_eh? Die shared libgcc (libgcc_s) benötigt man für exception support in c++?

comment:141 Geändert vor 4 Jahren durch er13

(In [6178]) gcc:

  • disable fixed-point support also for target-compiler
  • refs #842

comment:142 Geändert vor 4 Jahren durch ralf

(In [6179]) * GCC: disable mips16 float functions from libgcc_s

comment:143 als Antwort auf: ↑ 140 ; Antwort: Geändert vor 4 Jahren durch ralf

Replying to oliver:

Mag mir mal bitte noch jemand erklären was es mit dem statischen Linken und dem NEEDED Eintrag auf sich hat? Warum wird die libgcc nicht standardmäßig "shared" gelinkt?

static-libgcc:-lgcc -lgcc_eh
shared-libgcc:-lgcc_s -lgcc
standard:-lgcc --as-needed -lgcc_s --no-as-needed

Im oberen Beispiel sind bei ntpd alle Referenzen schon in der libgcc.a enthalten. Trotzdem wird in der Standard-Variante eine Referenz auf libgcc_s.so hinzugefügt, obwohl das --as-needed das meiner Meinung nach verhindern sollte. Als Folge sind sowohl alle benötigten Funktionen statisch zum Programm gelinkt als auch ein NEEDED-Eintrag für die libgcc_s.so vorhanden.

Das könnte ein Fehler im Linker sein, oder auch eine Folge von Weak/Alias Geschichten.

PS: Ich habe noch die mips16 Funktionen entfernt, die brauchen wir auch nicht. Damit haben wir nochmal ca. 10k weniger.

   text    data     bss     dec     hex filename
  68056    2272     544   70872   114d8 libgcc_s.so.1

Bei den sync-Funktionen bin ich mir nicht sicher, wir könnten die aber auch deaktivieren und abwarten, ob sie irgendwo fehlen.

Weiß jemand, wo und mit welchen CFLAGS die libgcc erstellt wird?

comment:144 Geändert vor 4 Jahren durch er13

libgcc? libgcc_s? libgcc_eh?

  • libgcc_eh.a - exception-handling Routinen
  • libgcc.a - alle anderen Routinen
  • libgcc_s.so - enthält pic-Versionen von den in libgcc.a und libgcc_eh.a enthaltenen Symbolen (allerdings nicht allen, in 0.9.28-4.4.5 mit disabled-fixed-point fehlen _eprintf und __gcc_bcmp)

comment:145 als Antwort auf: ↑ 143 Geändert vor 4 Jahren durch oliver

Replying to ralf:

Weiß jemand, wo und mit welchen CFLAGS die libgcc erstellt wird?

Ich nehme an in gcc/Makefile(.in) und dann noch source:trunk/toolchain/make/target/gcc/4.4.5/101-soft-float.patch

Kann man das so patchen, dass standardmäßig shared-libgcc gesetzt wird?

edit: OpenWRT macht das so? export libgcc_cv_fixed_point=no

comment:146 Antwort: Geändert vor 4 Jahren durch er13

Wenn wir -lgcc_s default machen möchten, müssten wir, wenn ich mich nicht irre, Zeile 1677 von gcc.c patchen.

Auf der anderen Seite scheint es deren Wunsch zu sein, libgcc statisch dazu zu linken. Man lese, man gcc /shared-libgcc n bzw. dasgleiche hier

comment:147 Geändert vor 4 Jahren durch er13

(In [6180]) gcc for target:

  • cleanup makefile, in particular eliminate code clones
  • refs #842

comment:148 Geändert vor 4 Jahren durch er13

(In [6181]) binutils for target:

  • bump version to 2.21.51.0.1

comment:149 Geändert vor 4 Jahren durch er13

(In [6185]) toolchain:

  • enable mips-plt optimizations for uClibc-0.9.28
  • refs #842

comment:150 Geändert vor 4 Jahren durch ralf

(In [6186]) GCC:

  • Optimize libgcc for space and for target CPU
  • refs #842

comment:151 als Antwort auf: ↑ 146 Geändert vor 4 Jahren durch ralf

Replying to er13:

Auf der anderen Seite scheint es deren Wunsch zu sein, libgcc statisch dazu zu linken.

So deutlich steht das dort nicht, wobei mich auch eine deutlichere Formulierung nicht unbedingt davon abhalten würde.

Letztlich ist es wohl eine Abwägung von Platzverbrauch gegen Geschwindigkeit, wobei wir ja mit -Os auch an anderen Stellen eher für den Platzverbrauch optimieren (AVM übrigens nicht).

Trotzdem würde ich es vorziehen, nicht den Default von GCC zu ändern, sondern die entsprechenden Optionen zu übergeben.

An passender Stelle libgcc_cv_fixed_point=no zu übergeben wäre auch eine Möglichkeit. Dann ist die Unterstützung im Compiler drin, aber nicht in der Library. Solange wir kein Programm haben, das darauf zugreift, ist das Ergebnis das gleiche.

PS: Ich habe die Optimierung beim Erstellen von libgcc geändert. Damit haben wir nochmal ca. 6k weniger.

   text    data     bss     dec     hex filename
  62104    2260     544   64908    fd8c libgcc_s.so.1

comment:152 Geändert vor 4 Jahren durch ralf

(In [6188]) GCC:

  • More changes for libgcc
  • refs #842

Noch einige Änderungen. Ich gehe davon aus, daß die entfernten Funktionen nicht benötigt werden. Etwas eleganter wäre es, die vollständig Library erstellen zu lassen, aber dann von den erstellten Objects die nicht verwendeten in libgcc_s zu entfernen. Programme, die zusätzliche Funktionen benötigen, könnten diese dann aus der statischen Library verwenden.

   text    data     bss     dec     hex filename
  52117    2248     544   54909    d67d libgcc_s.so.1

comment:153 Antwort: Geändert vor 4 Jahren durch er13

@Ralf: könntest Du bitte erklären, was es mit dem 800-libgcc-dwarf.patch auf sich hat (habe den Patch irgendwie gar nicht verstanden, vorallem den Zusammenhang mit der Größe von libgcc)?

Warum "-march=4kc -Os", zumindest -Os? Reicht denn —enable-target-optspace nicht aus?

Und 800-libgcc-disable-mips16-float.patch ist auch irgendwie eine Art Gewaltlösung… Würde denn

  • gcc/config.gcc

     
    15921592    ;; 
    15931593mips*-*-linux*)             # Linux MIPS, either endian. 
    15941594        tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h" 
    1595     tmake_file="${tmake_file} mips/t-libgcc-mips16" 
    15961595    case ${target} in 
    15971596        mipsisa32r2*) 
    15981597        tm_defines="${tm_defines} MIPS_ISA_DEFAULT=33" 

nicht reichen?

comment:154 als Antwort auf: ↑ 153 Geändert vor 4 Jahren durch ralf

Replying to er13:

könntest Du bitte erklären, was es mit dem 800-libgcc-dwarf.patch auf sich hat

Die Funktion __builtin_init_dwarf_reg_size_table (dwarf_reg_size_table) macht ungefähr folgendes:

  // 169 Zuweisungen in der Art:
  dwarf_reg_size_table[0] = 4;
  dwarf_reg_size_table[1] = 4;
  ...
  dwarf_reg_size_table[181] = 4;

Der ursprüngliche Code enthält 169 mal diesen Block:

        lw      v1,-32744(gp)
        nop
        sb      v0,6421(v1)

        lw      v1,-32744(gp)
        nop
        sb      v0,6422(v1)

Mit -march=4kc sieht es schon besser aus, 169 mal nop eingespart macht 169*4 Bytes

        lw      v1,-32744(gp)
        sb      v0,6421(v1)

        lw      v1,-32744(gp)
        sb      v0,6422(v1)

Mit dem Patch wird dwarf_reg_size_table erstmal der lokalen Variablen table zugewiesen, in der Hoffnung, daß der Compiler darauf verzichtet, immer wieder v1 mit dem gleichen Wert zu laden. Der Compiler ist aber so "schlau", daß er merkt, daß table den Wert von dwarf_reg_size_table hat und er sich die lokale Variable sparen kann und generiert den gleichen Code wie vorher. Daher noch die asm-Anweisung.

	  asm ("" : "=r" (table) : "0" (table)); 

Es ist eine leere Anweisung, die keinen Code generiert (der leere String am Anfang). Eingabe und Ausgabe dieser Anweisung ist jeweils die lokale Variable table. Da der Compiler nicht weiß, was die asm-Anweisung tut, ist für ihn danach der Wert von table unbekannt, so daß er wirklich den Wert nehmen muß, der in dem Register steht. Damit spart man noch einmal 168*4 Bytes ein:

        sb      v1,0(v0)

        sb      v1,1(v0)

Hintergrund ist, daß MIPS keine einzelne Anweisung hat um einen konstanten Wert an eine konstante Adresse zu schreiben, aber GCC das intern anscheinend für einzelne Anweisung hält. Der i386 oder x86 dagegen hat solche Anweisungen. Trotzdem würden auch auf diesen der Code kürzer mit diesem Patch (in Bytes, nicht in Anweisungen).

Es gäbe noch eine Möglichkeit, noch einige hundert Bytes einzusparen:

  memset (dwarf_reg_size_table, 4, sizeof (dwarf_reg_size_table));

Das ist nicht absolut identisch, tut es aber vielleicht auch. Der Unterschied ist, daß hier alle Bytes auf 4 gesetzt werden, während mit der ursprünglichen Funktion einige Bytes nicht gesetzt werden. Ich weiß nicht, ob irgendwo vorausgesetzt wird, daß die nicht gesetzten Werte auf 0 bleiben oder ob sie nicht von Bedeutung sind.

Dein Patch für mips16 sollte es auch tun. Ich hatte nicht länger gesucht, wo die Datei verwendet wird, aber es ist eleganter, die Datei stehen zu lassen und nur den Aufruf zu entfernen. Willst Du das ändern?

--enable-target-optspace aktiviert schon -Os, die Option könnte man also weglassen.

Die Option -march=4kc führt dazu, daß der Code besser auf die verwendete CPU angepasst wird, ebenso wie in den normalen Programmen. Da -Os sowieso schon aktiv war, ist der ganze Platzgewinn oben nur auf -march=4kc zurückzuführen.

comment:155 Antwort: Geändert vor 4 Jahren durch er13

Erstmal Danke, glaube es mal verstanden zu haben. Wo ist übrigens diese __builtin_init_dwarf_reg_size_table definiert?

comment:156 als Antwort auf: ↑ 155 Geändert vor 4 Jahren durch ralf

Replying to er13:

Wo ist übrigens diese __builtin_init_dwarf_reg_size_table definiert?

In gcc/dwarf2out.c:546 expand_builtin_init_dwarf_reg_sizes

comment:157 Antwort: Geändert vor 4 Jahren durch er13

Würde volatile vor unsigned char *table statt der asm-Anweisung nicht zum gleichen Ergebnis führen?

comment:158 als Antwort auf: ↑ 157 Geändert vor 4 Jahren durch ralf

Replying to er13:

Würde volatile vor unsigned char *table statt der asm-Anweisung nicht zum gleichen Ergebnis führen?

Das käme auf einen Versuch an:

test.c:41: warning: passing argument 1 of '__builtin_init_dwarf_reg_size_table' discards qualifiers from pointer target type
test.c:41: note: expected 'void *' but argument is of type 'volatile unsigned char *'

Nein, damit geht es nicht.

comment:159 Geändert vor 4 Jahren durch er13

(In [6192]) uClibc-0.9.28:

  • backport some missing math functions
  • increases libm by about 2KB
  • refs #842
  • refs #1070, fixes ffmpeg build problems

Geändert vor 4 Jahren durch oliver

comment:160 Geändert vor 4 Jahren durch er13

(In [6209]) toolchain:

  • upper-case cross_compiler/cross_compiler_kernel variables to avoid confusion with similar named targets (actually one target)
  • and eliminate this confusing target by replacing it with gcc target (both does the same)
  • refs #842

comment:161 Geändert vor 4 Jahren durch er13

(In [6210]) toolchain:

  • move definition of CROSS_COMPILER_KERNEL/CROSS_COMPILER variables to toolchain/make/Makefile.in
  • this allows us to remove all redundant definitions
  • refs #842

comment:162 Geändert vor 4 Jahren durch er13

(In [6211]) toolchain:

  • rename CROSS_COMPILER_KERNEL to KERNEL_CROSS_COMPILER and CROSS_COMPILER to TARGET_CROSS_COMPILER to correspond to the naming scheme used by other variables
  • refs #842

comment:163 Geändert vor 4 Jahren durch er13

(In [6212]) toolchain:

  • replace occurrences of (KERNEL|TARGET)_CROSS_COMPILER's value with reference to it
  • revise dependencies
  • refs #842

comment:164 Geändert vor 4 Jahren durch oliver

(In [6236]) [7390]: Add new download toolchains

  • kernel: mips(el)-gcc-3.4.6 and mips-gcc-4.4.5
  • target: mips(el)-gcc-4.4.5, uClibc-0.9.28/.29/.30.3
  • Update CHANGELOG
  • refs #842

comment:165 Geändert vor 4 Jahren durch ralf

(In [6239]) GCC:

  • don't include mips/t-libgcc-mips16 (by er13)
  • refs #842

comment:166 Geändert vor 4 Jahren durch ralf

Ich habe man den GCC 4.5.1 ausprobiert. Das Ergebnis ist soweit gut, die erzeugten Dateien sind etwas kleiner.

   text    data     bss     dec     hex filename
 551178    1721    5445  558344   88508 busybox-4.4.5
 548096    1629    5445  555170   878a2 busybox-4.5.1

Er benötigt aber zusätzlich die Library mpc.

comment:167 Geändert vor 4 Jahren durch er13

@ralf: r6248 ist vom Lesen her fehlerhaft. Ohne abspath in trunk/make/libs/mpfr.mk funktioniert die folgende Zeile nicht

$(PKG)_CONFIGURE_PRE_CMDS += $($(PKG)_PREVENT_AUTOCONF_CALL)

In trunk/toolchain/Config.in fehlt bei der Kombination 0.9.29/4.5.1

&& FREETZ_BUILD_TOOLCHAIN

Bei 0.9.3[01] ist dies nicht notwendig, da 0.9.3[01] an sich nur dann auswählbar sind, wenn die Toolchain selbst gebaut wird.

$(MPC_PREVENT_AUTOCONF_CALL) in trunk/make/libs/mpc.mk ist überflüssig.

In trunk/make/libs/Config.in fehlt der Eintrag für FREETZ_LIB_libmpc und in trunk/toolchain/Config.in der entsprechende Select bei config FREETZ_TARGET_TOOLCHAIN

comment:168 Geändert vor 4 Jahren durch ralf

Ich hatte hauptsächlich darauf geachtet, daß es auf dem Host funktioniert. Und nachdem man den Compiler auf dem Host erstellt hat, funktioniert es auch, den Compiler für die Box zu erstellen. Die Make-Abhängigkeiten sorgen auch dafür, daß die Libraries erstellt werden, man kann sie nur nicht getrennt in Menuconfig auswählen. Allerdings würde die Library nicht mit in ein Image aufgenommen werden. External wäre für diese Libraries noch interessant.

Daß die Host-Library auch in make/libs/mpfr.mk erstellt werden, finde ich nicht so gut. Ich habe jedenfalls erstmal gesucht, bis ich sie dort gefunden habe. MPFR_DIR2finde ich als Name auch nicht so gut. Besser HOST_MPFR_DIR. Ich würde generell HOST_ vorne im Namen verwenden, also HOST_MPFR_BINARY und nicht MPFR_HOST_BINARY, so wie bei host-libmpfr. Und bei den Quellen, die es unterstützen, könnte man die Pakete in ein anderes Verzeichnis auspacken, z.B. source/common und von dort aus in getrennte Verzeichnisse compilieren.

comment:169 Geändert vor 4 Jahren durch er13

Select in trunk/toolchain/Config.in ist leider immer noch falsch, libmpc soll nur bei gcc-4.5.1 ausgewählt werden. Und, wenn ich mich nicht irre, fehlt in trunk/toolchain/make/target/gcc/gcc.mk die Abhängigkeit von MPC (analog GMP bzw. MPFR, s. GCC_INITIAL_PREREQ bzw. GCC_TARGET_PREREQ), eventuell auch in binutils.mk.

Wegen Host-Library in make/libs/*.mk: gefällt mir auch nicht - feel free to change it ;-)

comment:170 Geändert vor 4 Jahren durch er13

(In [6268]) toolchain related part of menuconfig:

  • simplify implementation
  • revise/fix some dependencies
  • refs #842

comment:171 Antwort: Geändert vor 4 Jahren durch er13

(In [6274]) kernel-toolchain:

  • fix gmp/mpfr related options are always passed to kernel-binutils' and kernel-gcc' configure scripts (misspelled FREETZ_KERNEL_COMPILER_GCC_3_4_6 variable)
  • fix kernel & target toolchain prerequisites & configure options are messed up, because kernel-toolchain makefiles use the same variables as the target-toolchain ones (fixed by adding _KERNEL infix)
  • fix GCC_KERNEL_DECIMAL_FLOAT is defined but not passed to configure
  • refs #842

comment:172 Geändert vor 4 Jahren durch er13

(In [6275]) mpc for host:

  • fix mpc for host doesn't compile (it partially tries to use libraries under /lib instead of under $(TOOLS_BUILD_DIR), reason wrong *.la files under $(TOOLS_BUILD_DIR)/lib)
  • refs #842

comment:173 Geändert vor 4 Jahren durch er13

(In [6276]) target-toolchain:

  • fix gcc-4.5.1 doesn't compile
  • refs #842

comment:174 Geändert vor 4 Jahren durch er13

(In [6277]) target-toolchain:

comment:175 als Antwort auf: ↑ 171 ; Antwort: Geändert vor 4 Jahren durch ralf

Warum wird denn gmp und mpfr bei binutils gebraucht?

comment:176 Geändert vor 4 Jahren durch er13

(In [6287]) kernel-binutils:

  • sync version with target-binutils
  • refs #842

Geändert vor 4 Jahren durch er13

bin noch am testen, scheint aber mit allen Konfigurationen zu funktionieren (download-toolchain steht noch an)

comment:177 Geändert vor 4 Jahren durch er13

@Oliver: gäbe es da noch was zu tun außer kernel_headers and locales für BE?

comment:178 Geändert vor 4 Jahren durch oliver

Was ist mit den locales für BE? Das Thema war demletzt auch mal kurz auf der uClibc-Mailingliste. Aber ein konkretes Ergebnis gab's da nicht soweit ich mich erinnere.

#348 ist noch ein weiteres Problem mit den Kernel-Headern. Hast du eine Idee wie man das lösen könnte? Auf den ersten Blick scheint ein modsed (Kernel-Version in version.h ersetzen) als dirty-hack möglich. Funktioniert austauschen der kompletten Header ohne dass wir andere Header, aus bereits installierten Programmen/Libraries, verlieren? Ist nur asm(-generic)/linux nötig?

comment:179 Geändert vor 4 Jahren durch er13

@locales für BE: habe ich auch gelesen, habe das Gefühl, sie wissen es selbst nicht, ob es Endianness-/Arch-abhängig ist oder nicht.

@348: vom sed-Hack halte ich nichts, ist mir viel zu dirty! Ist denn uClibc-selbst kernel-Version abhängig? Wenn nein, dann könnten wir die kernel-Headers aus der download-toolchain rausnehmen und diese erst beim Build der Box entsprechend installieren, der kernel wird ja sowieso immer übersetzt.

p.s. oder wir schmeissen die download-toolchain à la openwrt einfach komplett raus ;-)

comment:180 Geändert vor 4 Jahren durch er13

(In [6289]) toolchain:

  • revise the way kernel headers are installed (use headers_install target where possible); fixes uClibc build problems with 2.6.28 kernel (7320)
  • based on oliver's patch provided in #842
  • refs #842

comment:181 Geändert vor 4 Jahren durch oliver

Ich würde die Download Toolchain gerne aus 2 Gründen behalten:

  1. Es verkürzt die Bauzeit für ein Image (für die User) erheblich. (30-45 Minuten)
  2. Ich als Dev muss nicht immer alle Kombinationen vorhalten, da die Download Toolchain sich schnell mal installieren lässt.

Da die mit Kernel 2.6.19.2 gebaute uclibc bis auf das IPv6 Problem auch auf 2.6.13.1 läuft denk ich, dass das okay ist. Ist es denn ausreichend wenn wir nur include/asm(-generic) und include/linux austauschen? Machen wir dadurch vielleicht ein anderes Package kaputt?

comment:182 Geändert vor 4 Jahren durch er13

Das mit dem rausschmeißen war nicht ernst gemeint ;-)

"Austauschen" ist vielleicht das falsche Wort. Ich schlage ja vor, gar keine kernel-Headers mit in das download-toolchain-tarball zu packen und stattdessen die Headers aus KERNEL_HEADERS_DEVEL_DIR erst zu Build-Zeit zu installieren. Ein anderes Package würden wir dann kaputt machen, wenn die erstellte uClibc auf der Binary-Ebene kernel-Version spezifisch ist.

comment:183 Geändert vor 4 Jahren durch er13

(In [6300]) gcc-4.5.1:

  • add missing patch
  • refs #842

comment:184 Antwort: Geändert vor 4 Jahren durch oliver

Sollen wir das Problem mit den Kernel-Headern auf später verschieben? Ich würde ein weiteres Toolchain Update vor 1.2 gerne vermeiden. Würde alle Boxen mit uClibc-0.9.29 und Kernel 2.6.13 (z.B. 7170, W900V) betreffen.

comment:185 als Antwort auf: ↑ 175 Geändert vor 4 Jahren durch er13

Replying to ralf:

Warum wird denn gmp und mpfr bei binutils gebraucht?

binutils kennt zwar die entsprechenden configure-switches, die Libraries scheinen aber vom greppen her nirgends verwendet zu werden. Ich überprüfe es mal und wenn es stimmt, schmeiße die Optionen und Abhängigkeiten raus…

comment:186 als Antwort auf: ↑ 184 Geändert vor 4 Jahren durch er13

Replying to oliver:

Sollen wir das Problem mit den Kernel-Headern auf später verschieben?

ich halte den Aufwand für relativ gering, daher eher nein, i.e. lass es uns in 1.2 machen

comment:187 Geändert vor 4 Jahren durch er13

In [6326]:

toolchain:

  • remove gcc 4.2.4 support
  • refs #842

comment:188 Geändert vor 4 Jahren durch er13

In [6327]:

kernel gcc-4.4.5:

  • use the same patches as the target gcc (part 1)
  • refs #842

comment:189 Geändert vor 4 Jahren durch er13

In [6328]:

kernel gcc-4.4.5:

  • use the same patches as the target gcc (part 2)
  • refs #842

comment:190 Geändert vor 4 Jahren durch dileks

Hallo zusammen,

nach einiger Abstinenz hab ich aus Interesse letzte Woche mal über die Toolchain Changes geschaut. Bemerkenswert, richtig toll. Auch in Bezug auf [1], wollte ich anmerken, dass binutils-2.21 (stable) vor ein paar Tagen released wurde. gcc-4.5.2-RC ist draussen und auch schon in Debian/experimental. Der Upstream-Maintainer will nächste Woche die Final releasen.

Mit Thorsten Glaser (MirBSD, Debian Developer m68k Toolchain, Portable Programmierung) hatte ich einige Diskussionen. Er ist vom H.J. Lu binutils nicht so angetan, z.B. da nur Linux-only angedacht. OK, Thorsten denkt mehr an Portierbarkeit :-). Vielleicht wäre es ratsamer auf die stabile binutils umzusteigen (man könnte sich auch die Debian Patches anschauen)?

Klar ist mir, alles mit Arbeit verbunden. Jemand sollte es machen. Persönlich, denke ich komme ich um die Jahreswende vllt. wieder zum Toolchain-Bau.

Noch eine Anmerkung: Ich hatte vor ein paar Monaten (angeregt über Diskussion im IRC mit oliver und er13) eine Wiki-Seite spez. zur neuen Toolchain erstellt. Auch hier kann ich erst wieder aktiv werden, wenn ich mal eine TC selber gebaut habe. Die involvierten Parteien soll es aber nicht abhalten, im Wiki zu wüten. Gute Projekte erkennt man an guter Dokumentation :-).

  • Sedat

[1] 7390 branch → trunk http://www.ip-phone-forum.de/showthread.php?t=227052

comment:191 Geändert vor 4 Jahren durch er13

In [6330]:

binutils:

  • drop dependencies on gmp/mpfr/mpc, binutils do not use these libraries at all
  • pointed out by Ralf, thanks for that
  • refs #842

Geändert vor 4 Jahren durch er13

Die Download-Toolchain muss nach dem Anwenden des Patches neu gebaut werden

comment:192 Geändert vor 4 Jahren durch oliver

Beim letzten Mal Download Toolchain bauen bin ich öfter darüber gestolpert, dass das stamp target für die kernel header ganz woanders liegt als die Header. Wenn man das Toolchain Verzeichnis per Hand löscht, dann werden die Header nicht neu installiert.

Brauchen wir neue Toolchains oder kann man einfach was aus den alten Archiven löschen und neu packen?

comment:193 Geändert vor 4 Jahren durch er13

Man kann auch einfach die Kernel-Headers löschen:

include/asm
include/asm-generic
include/drm
include/linux
include/mtd
include/rdma
include/scsi
include/sound
include/video

comment:194 Geändert vor 4 Jahren durch er13

In [6349]:

toolchain:

  • bump gcc version to 4.5.2
  • bump binutils version to 2.21.51.0.4
  • refs #842

Geändert vor 4 Jahren durch oliver

Build i386 toolchain even on x64 host

comment:195 Geändert vor 4 Jahren durch oliver

Der angehängte Patch ist ein erster Versuch eine 32-Bit Toolchain auf einem 64-Bit Host zu bauen. Wenn wir das aufnehmen sollten wir die Verwendung der Flags natürlich noch mit einer menuconfig Option kapseln.

comment:196 Geändert vor 4 Jahren durch oliver

@er13

Ich hab dein download-toolchain_right-kernel-headers-Patch ausprobiert. Sehe ich es richtig, dass die Header nur einmalig installiert werden? Wenn ich also zuerst ein Image für die 7270 und dann eins für die 7170 bauen möchte, dann bringt der Patch nichts?

Geändert vor 4 Jahren durch oliver

comment:197 Geändert vor 4 Jahren durch er13

Das siehst Du richtig, das sollte aber leicht zu korrigieren sein. Welche Pakete sind übrigens Kernel-Version abhängig, diese sollten entsprechend markiert werden, damit sie beim Kernel-Wechsel neu gebaut werden - fuse, radvd (noch nicht markiert), sonst welche?

comment:198 Geändert vor 4 Jahren durch er13

In [6377]:

binutils & gcc:

  • add patches which force binutils & gcc to use bundled version of mkstemps-function even on systems with GLIBC ≥ 2.11 (needed for dynamically linked download toolchain)
  • refs #842

comment:199 Geändert vor 4 Jahren durch er13

In [6378]:

target-toolchain:

  • remove binutils-2.18, it was needed for gcc-4.2.4 (removed in r6326)
  • refs #842

Geändert vor 4 Jahren durch er13

Geändert vor 4 Jahren durch er13

comment:200 Geändert vor 4 Jahren durch er13

Mit den beiden Patches oben (minimize_required_glibc___i386_toolchain.patch und apgcc.patch) kann ich eine dynamisch gelinkte Toolchain bauen, die lediglich glibc-2.3.4 (eine mehr als 5 Jahre alte Version) als Abhängigkeit hat (auch 32-Bit auf einem 64-bit System). Es gibt allerdings noch einige Probleme:

  1. apgcc ist noch nicht integriert, muss separat installiert werden und zwar letzte trunk Version (svn co svn://plan99.net/apbuild/trunk apbuild) mit dem apgcc.patch. Schwierigkeiten bereitet wilde Abhängigkeit zu der vala-Sprache. Ich könnte allerdings das entsprechende Binary statisch bauen und dazu packen, spreche was dagegen?
  2. 64-bit fakeroot weigert sich dynamisch gelinktes 32-bit Binary auszuführen bzw. LD_PRELOAD von libfakeroot.so scheitert.

p.s. falls jemand den Patch testen möchte, es werden folgende Dateien aus apbuild gebraucht: apgcc, buildlist (muss aus buildlist.vala erstellt werden), Apbuild/GCC.pm und Apbuild/Utils.pm

comment:201 Geändert vor 4 Jahren durch er13

In [6379]:

fakeroot:

  • build both x64 and x86 libfakeroot on biarch systems
  • refs #1089, refs #842

comment:202 Antwort: Geändert vor 4 Jahren durch er13

In [6380]:

toolchain:

  • add a couple of CFLAGS-based tricks which allow to minimize the GLIBC version required for dynamically linked download-toolchain
  • add menuconfig option which allows to create a 32-bit toolchain on the 64-bit build-systems (based on Oliver's patch provided in #842)
  • refs #842, refs #1089

comment:203 Geändert vor 4 Jahren durch er13

Ich habe festgestellt, dass wir mit sehr hoher Wahrscheinlichkeit gar kein apgcc brauchen. Auf meinem Ubuntu 10.04 entstehen auch ohne apgcc toolchains, die lediglich glibc-2.3.4 voraussetzen. Zur Sicherheit müsste mal jemand auf einem System mit glibc-2.12.* die toolchains bauen und mit

readelf -a $(toolchain_binaries) | grep "GLIBC_2[.]1[0-9]"
bzw.
objdump -T $(toolchain_binaries) 2>/dev/null | grep GLIBC | sed -r -e 's,.*(GLIBC.*),\1,g' | sort -u

überprüfen.

Geändert vor 4 Jahren durch er13

korrigierte Version des right-kernel-header-Patches

Geändert vor 4 Jahren durch er13

etwas vereinfachte Version

comment:204 als Antwort auf: ↑ 202 ; Antwort: Geändert vor 4 Jahren durch dileks

Replying to er13:

In [6380]:

toolchain:

  • add a couple of CFLAGS-based tricks which allow to minimize the GLIBC version required for dynamically linked download-toolchain
  • add menuconfig option which allows to create a 32-bit toolchain on the 64-bit build-systems (based on Oliver's patch provided in #842)
  • refs #842, refs #1089

Warum ist -m32 hier hardgecoded? (Ich habe mir nur das Changes-Fragment aus r6380 angeschaut.)

[ trunk/toolchain/make/target/uclibc/uclibc.mk ]

HOSTCC="$(HOSTCC)" \
HOSTCC="$(TOOLCHAIN_HOSTCC) $(UCLIBC_HOST_CFLAGS) -m32" \ 
BUILD_LDFLAGS="$(if $(FREETZ_STATIC_TOOLCHAIN),-static)" \

Versus

[ trunk/toolchain/make/toolchain-common.in ]

ifeq ($(strip $(FREETZ_BUILD_32BIT_TOOLCHAIN)),y) 
TOOLCHAIN_HOST_CFLAGS+=-m32 
endif

Wäre eine Prüfung/Einführung in uclibc.mk auf 32-bit Toolchain wie in toolchain-common.in nicht sinnvoll?

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

comment:205 als Antwort auf: ↑ 204 ; Antwort: Geändert vor 4 Jahren durch oliver

Replying to dileks:

Wäre eine Prüfung/Einführung in uclibc.mk auf 32-bit Toolchain wie in toolchain-common.in nicht sinnvoll?

Nein, das behebt einen Fehler. Wenn der Host-ldd mit einem 64-Bit gcc gebaut wird, dann funktioniert er nicht, weil wir für die Box 32-Bit Binaries bauen. Ich hatte dazu schon auf der uClibc-Mailingliste angefragt aber keine Antwort erhalten.

comment:206 als Antwort auf: ↑ 205 Geändert vor 4 Jahren durch dileks

Replying to oliver:

Replying to dileks:

Wäre eine Prüfung/Einführung in uclibc.mk auf 32-bit Toolchain wie in toolchain-common.in nicht sinnvoll?

Nein, das behebt einen Fehler. Wenn der Host-ldd mit einem 64-Bit gcc gebaut wird, dann funktioniert er nicht, weil wir für die Box 32-Bit Binaries bauen. Ich hatte dazu schon auf der uClibc-Mailingliste angefragt aber keine Antwort erhalten.

ldd? Gemäss [1] und folgende Zeilen betrifft das mit "-m32" den Bau der Host-Utils. Ich dachte eher "-m32" nach BUILD_CFLAGS zu verfrachten (s.w.o. TOOLCHAIN_HOST_CFLAGS+=-m32). In jedem Fall wäre ein Kommentar angebracht - als Aussensteher kann ich nicht wissen warum, im Commit-Body zu r6380 auch keine Erklärung.

# Force building 32-bit host-utils via -m32 gcc flag (workaround when building on a 64-Bit host)
HOSTCC="$(TOOLCHAIN_HOSTCC) $(UCLIBC_HOST_CFLAGS) -m32" \

[1] trunk/toolchain/make/target/uclibc/uclibc.mk#L147

Zuletzt geändert vor 4 Jahren von oliver (vorher) (Diff)

comment:207 Antwort: Geändert vor 4 Jahren durch oliver

@er13 Die zweite Version des Kernel-Header Patches sieht besser aus. Ich denke, dass ndas noch eine Rebuild-Option benötigt. autofs nicht, weil die Module im Kernel gebaut werden.

Wie ist das mit den Kernel-Headers, wenn ich eine Toolchain selbst baue, diese aber mit dirclean wiederr lösche? Wird dann die Stamp-Datei (.headers_installed) mit gelöscht oder läuft der Build beim nächsten make in einen Fehler? Ich hatte den jetzt, da die Stamp Datei schon vorhanden war, aber in der jetzigen svn-Version noch keine Header kopiert wurden.

Oder als Frage formuliert: Sollen wir nicht statt dem .headers_installed konkret auf die Datei include/version.h prüfen?

comment:208 Geändert vor 4 Jahren durch er13

In [6383]:

toolchain:

  • document hardcoded -m32 option as requested by dileks
  • refs #842

comment:209 Geändert vor 4 Jahren durch er13

In [6384]:

toolchain:

  • exclude kernel-headers from the download-toolchain
  • install the right ones at the build-time
  • refs #842, refs #348

comment:210 als Antwort auf: ↑ 207 Geändert vor 4 Jahren durch er13

Replying to oliver:

Sollen wir nicht statt dem .headers_installed konkret auf die Datei include/version.h prüfen?

Macht Sinn, hab' Deinen Vorschlag umgesetzt und in r6384 eingecheckt…

comment:211 Geändert vor 4 Jahren durch er13

In [6386]:

  • fix r6384, uClibc-0.9.28 requires kernel headers a bit earlier
  • refs #842

Geändert vor 4 Jahren durch oliver

64-Bit Ubuntu Maverick mit -m32

comment:212 Geändert vor 4 Jahren durch oliver

Angehängt die Ausgabe von objdump für die Toolchain Binaries, gebaut auf einem 64-Bit Ubuntu Maverick (libc6). Die höchste glibc Version ist 2.3.4:

GLIBC_2.3.4 __fprintf_chk
GLIBC_2.3.4 __printf_chk
GLIBC_2.3.4 __sprintf_chk
GLIBC_2.3.4 __strcat_chk
GLIBC_2.3.4 __strcpy_chk
GLIBC_2.3.4 __vfprintf_chk

Sieht also gut aus oder? Soll ich mal eine Runde Toolchains damit bauen?

Können wir eigentlich eine rudimentäre Prüfung einbauen, ob die Download-Toolchain unter dem verwendeten System läuft?

comment:213 Geändert vor 4 Jahren durch oliver

In [6387]:

  • Update download toolchains (only target toolchains are updated)
    • only kernel headers were removed
    • refs #842

comment:214 Geändert vor 4 Jahren durch er13

Replying to oliver:

Sieht also gut aus oder? Soll ich mal eine Runde Toolchains damit bauen?

Ja, sieht gut aus. Kannst Du machen, ich habe allerdings schon alle gebaut. Wenn Du also nicht unbedingt scharf drauf bist, kannst mir (per Mail?) die Zugangsdaten zu dem ftp zukommen lassen, ich werde sie heute Abend hochladen.

Können wir eigentlich eine rudimentäre Prüfung einbauen, ob die Download-Toolchain unter dem verwendeten System läuft?

Meinst Du einen einfachen glibc-Versionscheck nach dem Entpacken oder auch noch dass alle notwendigen 32-bit Libraries installiert sind?

comment:215 Geändert vor 4 Jahren durch oliver

In [6388]:

  • Copy some more kernel headers for 2.6.13.1 (refs #842)

comment:216 Geändert vor 4 Jahren durch er13

In [6392]:

toolchains:

  • update download toolchains
  • the new toolchains are linked dynamically against GLIBC (the old ones were linked statically) and thus require at least GLIBC-2.3.4 to be installed on the build system (2.3.4 is more than 5 years old, most recent linux distributions use GLIBC ≥ 2.10, so this is not expected to be a problem)
  • refs #842
  • refs #1089 (the new toolchains are actually expected to fix this ticket, we just wanna get more user feedback before closing it)

Geändert vor 4 Jahren durch oliver

comment:217 Geändert vor 4 Jahren durch er13

Aus der Mail von Oliver an mich: Scheint so als dürften wir include/scsi nicht aus der Download-Toolchain löschen. Da sollten eigentlich die uClibc-Header drin sein. http://www.mail-archive.com/linux-scsi/vger.kernel.org/msg09141.html

Zuletzt geändert vor 4 Jahren von er13 (vorher) (Diff)

comment:218 Geändert vor 4 Jahren durch er13

Auch wenn die Änderung von Olaf Hering es mal ins Kernel-Repository geschafft hat, wurde sie inzwischen wieder rückgängig gemacht. Ich weiß nicht, wie es mit glibc aussieht, aber in uClibc wurden die Headers 2004 einmalig importiert und seitdem nie wieder aktualisiert. uClibc referenziert diese Headers auch gar nicht, die sind einfach da und werden, wenn überhaupt, nur mit installiert. Ich verstehe auch nicht was das SCSI-Interface in libc verloren hat, ist bestimmt kein Teil des C89 bzw. C99 Standards. Daher halte ich es für richtig, dass wir die SCSI-Headers aus dem Kernel verwenden. D.h. um das Problem zu lösen, sollten wir diese Änderung für 2.6.28 einfach wieder rückgängig machen.

comment:219 Geändert vor 4 Jahren durch oliver

Gut, dann machen wir es so rum. Hat außerdem den Vorteil, dass wir nichts an den Toolchains ändern müssen.

comment:220 Geändert vor 4 Jahren durch cuma

Hab hier noch ein paar Probleme mit aktellem Trunk, bin aber nicht sicher ob es mit der toolchain zusammenhängt. Der download_toolchain_fix_scsi_headers.patch hatte nicht geholfen (oder ich hab ein dirclean vergessen)

Geändert vor 4 Jahren durch cuma

Geändert vor 4 Jahren durch cuma

Geändert vor 4 Jahren durch cuma

comment:221 Geändert vor 4 Jahren durch oliver

  • ip6tables: Passiert das mit aktuellem trunk auch noch? (nach "make iptables-dirclean) Ich vermute, dass er ipv6=no gecached hat. Eigentlich sollte er den Wert jetzt nicht mehr aus dem Cache abfragen?

Für 2.6.28 brauchts auch noch scsi-Header Patches:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f290f1970f01287eaaffc798a677594a57ebd65e http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=083c8c1e60e5c27a277e87dbeb6b89b47937559f

Wobei ich gerade sehe, dass die Änderung ja schon wieder Rückgängig gemacht wurde: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7407e5bba2cc821950344fd1391d9ad1b7e0b397

Was ist denn das für ein durcheinander? :-)

comment:222 Geändert vor 4 Jahren durch cuma

  • minicom: war vor und nach Checkin r6398 so. Wobei der eh nur für uclib 0.9.28 Wirkung hat (7170 nutzt 0.9.29)
  • ip6tables: Müsste. Hab die genaue Revision nicht mehr, teste ich nochmal. Der Fehler kam immer so: 7141 mit replace kernel ohne ipv6 gebaut, dann ipv6 aktivert und wieder gebaut

comment:223 Geändert vor 4 Jahren durch por

make ends with an error while building fakeroot.

[...]
checking whether the C compiler works... no
configure: error: in `/home/paul/freetz-trunk/source/host-tools/fakeroot-1.14.5/build/biarch':
configure: error: C compiler cannot create executables
See `config.log' for more details
make: *** [/home/paul/freetz-trunk/source/host-tools/fakeroot-1.14.5/build/biarch/.configured] Error 77

Host is x86_64.

Geändert vor 4 Jahren durch por

config.log of config error for fakeroot

comment:224 Geändert vor 4 Jahren durch er13

@por: s. here

comment:225 Geändert vor 4 Jahren durch er13

In [6409]:

kernel-2.6.19:

  • make scsi headers user-space friendly
  • refs #842, refs #1156

comment:226 Geändert vor 4 Jahren durch er13

In [6410]:

kernel-2.6.28:

  • export scsi headers, make them user-space friendly
  • refs #842, refs #1156

In order to get corrected headers installed in toolchain staging dir, users should

  • either start with a fresh checkout
  • or run the following commands: make kernel-distclean; rm -rf toolchain/build/mips*uClibc*/mips*uclibc/usr/include/linux

comment:227 Geändert vor 4 Jahren durch BtbN

Beobachtet mit Revision 6411:

$ make
which: no jam in (/home/btbn/.bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2:/usr/games/bin:/opt/cuda/bin)
WARNING: The program jam was not found in path.
find: `/usr/local/include/': Datei oder Verzeichnis nicht gefunden
find: `/usr/local/include/': Datei oder Verzeichnis nicht gefunden
cmd() { PATH="/home/btbn/Projekte/Freetz/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/bin:/home/btbn/Projekte/Freetz/toolchain/build/mips_gcc-3.4.6/mips-unknown-linux-gnu/bin:/home/btbn/.bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2:/usr/games/bin:/opt/cuda/bin" LD_RUN_PATH="/usr/lib/freetz" make -j8  "$@"  || { printf "\n\\033[33m%s\\033[m\n" "ERROR: Build failed.";  exit 1; } };       if [ -e source/.echo_item_start -a ! -e source/.echo_item_build ]; then echo -n "building... "; touch source/.echo_item_build; fi; cmd -C source/target-mips_uClibc-0.9.29/mpc-0.8.2
make[1]: Entering directory `/home/btbn/Projekte/Freetz/source/target-mips_uClibc-0.9.29/mpc-0.8.2'
make  all-recursive
make[2]: Entering directory `/home/btbn/Projekte/Freetz/source/target-mips_uClibc-0.9.29/mpc-0.8.2'
Making all in src
make[3]: Entering directory `/home/btbn/Projekte/Freetz/source/target-mips_uClibc-0.9.29/mpc-0.8.2/src'
/bin/sh ../libtool --tag=CC   --mode=link /home/btbn/Projekte/Freetz/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/bin/mips-linux-uclibc-gcc  -Os -pipe -march=4kc -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -version-info 2:0:0  -o libmpc.la -rpath /usr/lib abs.lo acos.lo acosh.lo add.lo add_fr.lo add_ui.lo arg.lo asin.lo asinh.lo atan.lo atanh.lo clear.lo cmp.lo cmp_si_si.lo conj.lo cos.lo cosh.lo div_2exp.lo div.lo div_fr.lo div_ui.lo exp.lo fr_div.lo fr_sub.lo get_prec2.lo get_prec.lo get_str.lo get_version.lo imag.lo init2.lo init3.lo inp_str.lo log.lo mem.lo mul_2exp.lo mul.lo mul_fr.lo mul_i.lo mul_si.lo mul_ui.lo neg.lo norm.lo out_str.lo pow.lo pow_fr.lo pow_ld.lo pow_d.lo pow_si.lo pow_ui.lo pow_z.lo proj.lo real.lo urandom.lo set.lo set_prec.lo set_str.lo set_x.lo set_x_x.lo sin.lo sinh.lo sqr.lo sqrt.lo strtoc.lo sub.lo sub_fr.lo sub_ui.lo swap.lo tan.lo tanh.lo uceil_log2.lo ui_div.lo ui_ui_sub.lo  -lmpfr -lgmp 
libtool: link: /home/btbn/Projekte/Freetz/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -shared  .libs/abs.o .libs/acos.o .libs/acosh.o .libs/add.o .libs/add_fr.o .libs/add_ui.o .libs/arg.o .libs/asin.o .libs/asinh.o .libs/atan.o .libs/atanh.o .libs/clear.o .libs/cmp.o .libs/cmp_si_si.o .libs/conj.o .libs/cos.o .libs/cosh.o .libs/div_2exp.o .libs/div.o .libs/div_fr.o .libs/div_ui.o .libs/exp.o .libs/fr_div.o .libs/fr_sub.o .libs/get_prec2.o .libs/get_prec.o .libs/get_str.o .libs/get_version.o .libs/imag.o .libs/init2.o .libs/init3.o .libs/inp_str.o .libs/log.o .libs/mem.o .libs/mul_2exp.o .libs/mul.o .libs/mul_fr.o .libs/mul_i.o .libs/mul_si.o .libs/mul_ui.o .libs/neg.o .libs/norm.o .libs/out_str.o .libs/pow.o .libs/pow_fr.o .libs/pow_ld.o .libs/pow_d.o .libs/pow_si.o .libs/pow_ui.o .libs/pow_z.o .libs/proj.o .libs/real.o .libs/urandom.o .libs/set.o .libs/set_prec.o .libs/set_str.o .libs/set_x.o .libs/set_x_x.o .libs/sin.o .libs/sinh.o .libs/sqr.o .libs/sqrt.o .libs/strtoc.o .libs/sub.o .libs/sub_fr.o .libs/sub_ui.o .libs/swap.o .libs/tan.o .libs/tanh.o .libs/uceil_log2.o .libs/ui_div.o .libs/ui_ui_sub.o   -Wl,-rpath -Wl,/home/btbn/Projekte/Freetz/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/usr/lib -Wl,-rpath -Wl,/home/btbn/Projekte/Freetz/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/usr/lib /usr/lib/libmpfr.so /home/btbn/Projekte/Freetz/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/usr/lib/libgmp.so  -march=4kc   -Wl,-soname -Wl,libmpc.so.2 -o .libs/libmpc.so.2.0.0                                                                                          
/usr/lib/libmpfr.so: could not read symbols: File in wrong format                                                                
collect2: ld returned 1 exit status                                                                                              
make[3]: *** [libmpc.la] Fehler 1                                                                                                
make[3]: Leaving directory `/home/btbn/Projekte/Freetz/source/target-mips_uClibc-0.9.29/mpc-0.8.2/src'                           
make[2]: *** [all-recursive] Fehler 1                                                                                            
make[2]: Leaving directory `/home/btbn/Projekte/Freetz/source/target-mips_uClibc-0.9.29/mpc-0.8.2'                               
make[1]: *** [all] Fehler 2                                                                                                      
make[1]: Leaving directory `/home/btbn/Projekte/Freetz/source/target-mips_uClibc-0.9.29/mpc-0.8.2'                               
                                                                                                                                 
ERROR: Build failed.                                                                                                             
make: *** [source/target-mips_uClibc-0.9.29/mpc-0.8.2/src/.libs/libmpc.so.2.0.0] Fehler 1

Gefixt durch temporäres umbenennen der System eigenen libmpfr.so, welche natürlich nicht für mips gebaut ist ;) make sollte die finger von der system lib lassen, und die zuvor gebaute für mips benutzen, was er auch tut, wenn ich die system lib kurz weg-umbenenne.

comment:228 Geändert vor 4 Jahren durch oliver

In [6412]:

  • Fix mpc build
    • Fix libdir in libmpfr.la and libmpc.la otherwise libtool searches in /usr/lib
    • refs #842

comment:229 Geändert vor 4 Jahren durch oliver

In [6467]:

ccache:

  • Bump version to 3.1.4
  • Fix typo in download rule
  • Only move if checked file is not a symlink *refs #842

comment:230 Geändert vor 4 Jahren durch oliver

In [6638]:

  • Bump binutils to version 2.21.51.0.6 (refs #842)
    • uClibc-0.9.31 fails to build with 2.21.51.0.7

comment:230 Geändert vor 4 Jahren durch oliver

In [6639]:

  • Bump binutils to version 2.21.51.0.6 (refs #842)
    • uClibc-0.9.31 fails to build with 2.21.51.0.7

comment:231 Geändert vor 4 Jahren durch oliver

In [6640]:

  • Add some uClibc-0.9.31 patches from OpenWRT (refs #842)

comment:232 Antwort: Geändert vor 4 Jahren durch dileks

Beim Übersetzen von gcc-4.6 auf meinem x86_32 Debian Host, bin ich nochmals über die configure-option "—disable-cxa_atexit" gestolpert (initial + final stages im gcc-uclibc-TC-Bau).

Frage: War diese Option notwendig in Verbindung mit uClibc++?

Beim Stöbern habe ich gesehen, dass Patch "eh: Add alloc/free for dependent exception" [1] jetzt in uClibc++ GIT master verfügbar ist. Der Patch "990-dependent_exception.patch" von OpenWRT im freetz Buildsystem ist damit auch erledigt. Letzter commit 7efcc107b6bf7a59a85beaf7c7f35da6de0f321e ("tests: fix typo")

Einen Dateinamen wie "uClibc++-5976d7536d8c7a8d5a7f60fd2a3c34876a224f30.tar.bz2" (letzte verfügbare Version) finde ich nicht besonders gelungen. Ich habe uClibc++ mal lokal gebaut, Resultat ist "./src/libuClibc++-0.2.3.so". Weiterhin würde ich sehr stark dafür plädieren eigene Tarballs mit XZ zu komprimieren. IMHO könnte das neue Tarball "uClibc++-0.2.3+git20101121.7efcc10.tar.xz" heissen.

[1]http://git.busybox.net/uClibc++/commit/?id=230a42db9254919a1067c6b2fca31d9fccdf5660

comment:233 Geändert vor 4 Jahren durch dileks

Ich habe Upstream gefragt, ob man eine v0.2.4 zur Verfügung stellen kann.

comment:234 Geändert vor 4 Jahren durch dileks

$ du -h dl/uClibc++-5976d7536d8c7a8d5a7f60fd2a3c34876a224f30.tar.*
252K    dl/uClibc++-5976d7536d8c7a8d5a7f60fd2a3c34876a224f30.tar.bz2
224K    dl/uClibc++-5976d7536d8c7a8d5a7f60fd2a3c34876a224f30.tar.xz
Zuletzt geändert vor 4 Jahren von dileks (vorher) (Diff)

comment:235 Antwort: Geändert vor 4 Jahren durch oliver

Mail vom uClibc++-Maintainer: http://lists.uclibc.org/pipermail/uclibc/2011-January/044683.html

Passiert ist jedoch bisher nichts. Ich kann auf der Liste mal nachfragen…

comment:236 als Antwort auf: ↑ 232 ; Antwort: Geändert vor 4 Jahren durch er13

Replying to dileks:

Einen Dateinamen wie "uClibc++-5976d7536d8c7a8d5a7f60fd2a3c34876a224f30.tar.bz2" (letzte verfügbare Version) finde ich nicht besonders gelungen. Ich habe uClibc++ mal lokal gebaut, Resultat ist "./src/libuClibc++-0.2.3.so". Weiterhin würde ich sehr stark dafür plädieren eigene Tarballs mit XZ zu komprimieren. IMHO könnte das neue Tarball "uClibc++-0.2.3+git20101121.7efcc10.tar.xz" heissen.

Manchmal wundere ich mich, was alles kritisiert wird…

Es ist kein eigenes Tarball, den Namen haben wir uns nicht ausgedacht - es ist die git-commit-Id (falls Dir diese nicht gefällt, wende Dich an Linus bitte ;-)). Die Datei ist hier verfügbar.

comment:237 als Antwort auf: ↑ 236 ; Antwort: Geändert vor 4 Jahren durch dileks

Replying to er13:

Replying to dileks:

[…] IMHO könnte das neue Tarball "uClibc++-0.2.3+git20101121.7efcc10.tar.xz" heissen.

Manchmal wundere ich mich, was alles kritisiert wird…

Es ist kein eigenes Tarball, den Namen haben wir uns nicht ausgedacht - es ist die git-commit-Id (falls Dir diese nicht gefällt, wende Dich an Linus bitte ;-)). Die Datei ist hier verfügbar.

Keine Ahnung was Linus mit der Sache zu tun hat, der ist momentan mit dem Merge-Window zu 2.6.39 gut ausgelastet. Das sowas wie $SCM_GIT_URL/$PKGNAME/snapshot/$PKGNAME-$GITHASH.tar.$COMPRESSOR funktioniert ist dem jenigen zu verdanken, der das GIT-Repo (plus Drumherum wie z.B. auf Anfrage automatisch Archive erstellen) aufgesetzt hat. Auch wenn der $GITHASH eindeutig ist, sagt er aber nichts über die (so-)Version der uClibc++ aus. Obiger gewünschter Version-String ist absolut geläufig, z.B. in vielen Debian Snapshot Paketen. Ausserdem sind meine Anmerkungen eher als Wunsch und nicht als Forderungen zu verstehen.

comment:238 als Antwort auf: ↑ 235 Geändert vor 4 Jahren durch dileks

Replying to oliver:

Mail vom uClibc++-Maintainer: http://lists.uclibc.org/pipermail/uclibc/2011-January/044683.html

Passiert ist jedoch bisher nichts. Ich kann auf der Liste mal nachfragen…

JA, das wäre nett. Im GIT-Repo auf <http://git.busybox.net/uClibc++/> sehe ich aber keinen einzigen Commit von Garrett Kajmowicz, daher hatte ich Bernhard direkt angeschrieben (am besten per CC an ihn).

comment:239 als Antwort auf: ↑ 237 ; Antwort: Geändert vor 4 Jahren durch ralf

Replying to dileks:

Keine Ahnung was Linus mit der Sache zu tun hat

Linus hat git erstellt und beschlossen, daß jeder Commit nicht eine fortlaufende Nummer, sondern einen Hash hat.

Die Datei wird nicht von uns zur Verfügung gestellt, also haben wir auch wenig Einfluß darauf, wie sie heißt. Und wie würden wir reagieren, wenn jemand daher käme und sagt "Der Name Eurer Freetz Datei gefällt mir nicht, nennt die noch mal anders"?

comment:240 Geändert vor 4 Jahren durch dileks

OK, ich bin davon ausgegangen das Tarball käme von einem der freetz-Mirrors. Mea culpa.

[ make/libs/uclibc++.mk ]
$(call PKG_INIT_LIB, 5976d7536d8c7a8d5a7f60fd2a3c34876a224f30, uclibcxx)
...
$(PKG)_SITE:=http://git.uclibc.org/uClibc++/snapshot
$(PKG)_DIR:=$($(PKG)_SOURCE_DIR)/uClibc++-$($(PKG)_VERSION)
Zuletzt geändert vor 4 Jahren von dileks (vorher) (Diff)

comment:241 als Antwort auf: ↑ 239 Geändert vor 4 Jahren durch dileks

Replying to ralf:

Replying to dileks:

Keine Ahnung was Linus mit der Sache zu tun hat

Linus hat git erstellt und beschlossen, daß jeder Commit nicht eine fortlaufende Nummer, sondern einen Hash hat.

Ich glaube kaum, dass Linus das Repo auf <http://git.busybox.net/> (so) augesetzt hat, dass Snapshot Tarballs (automatisch) heruntergeladen werden können. Dazu bezog sich mein Kommentar.

comment:242 Geändert vor 4 Jahren durch oliver

In [6713]:

  • uclibc: Allow building in parallel mode for 0.9.31 (refs #842)

comment:243 Geändert vor 4 Jahren durch dileks

Wenn ich obigen Commit gerade sehe… Ich jage gerade einen Bug zwischen uClibc-0.9.32-rc3 und binutils-2.21. make V=1 in uclibc.mk gibt nicht die "full gcc-line" zurück (im build-log sehe ich, dass V=1 in der make-line hinzugefügt wurde). Kann sich das jemand bei Gelegenheit anschauen?

[ nach build break, erneut make aufgerufen ]
make -C /home/sd/src/freetz/freetz-trunk/source/toolchain-mipsel_gcc-4.6.0-RC-20110314_uClibc-0.9.32-rc3/uClibc-0.9.32-rc3 \
                LOCALE_DATA_FILENAME=uClibc-locale-le-32-de_DE-en_US.tar.gz V=1 \
                PREFIX= \
                DEVEL_PREFIX=/ \
                RUNTIME_PREFIX=/ \
                HOSTCC="gcc -Wa,--size-check=warning  -D_GNU_SOURCE -fno-stack-protector -U_GNU_SOURCE -fno-strict-aliasing" \
                all
make[1]: Entering directory `/home/sd/src/freetz/freetz-trunk/source/toolchain-mipsel_gcc-4.6.0-RC-20110314_uClibc-0.9.32-rc3/uClibc-0.9.32-rc3'
make[2]: Nothing to be done for `locale_headers'.
  AS lib/crtn.o -DNDEBUG -D__ASSEMBLER__
initfini.c: Assembler messages:
initfini.c:47: Error: .size expression for _init does not evaluate to a constant
initfini.c:47: Error: .size expression for _fini does not evaluate to a constant
make[1]: *** [lib/crtn.o] Fehler 1
make[1]: Leaving directory `/home/sd/src/freetz/freetz-trunk/source/toolchain-mipsel_gcc-4.6.0-RC-20110314_uClibc-0.9.32-rc3/uClibc-0.9.32-rc3'
make: *** [/home/sd/src/freetz/freetz-trunk/source/toolchain-mipsel_gcc-4.6.0-RC-20110314_uClibc-0.9.32-rc3/uClibc-0.9.32-rc3/lib/libc.a] Fehler 2
Zuletzt geändert vor 4 Jahren von dileks (vorher) (Diff)

comment:244 Antwort: Geändert vor 4 Jahren durch er13

Und schon mal nach der Fehlermeldung gegoogelt?

p.s. Kannst Du bitte mal erklären, was Dir dieses "being on the bleeding edge" (gcc-4.6snapshot, uClibc-0.9.32rc) bringt? Ich verwende z.B. weiterhin gcc-4.4.x, gcc-4.5.x erzeugt zwar etwas kleinere Binaries, diese lassen sich aber schlechter komprimieren, sodass das fertige Image dann größer wird.

comment:245 als Antwort auf: ↑ 244 ; Antwort: Geändert vor 4 Jahren durch oliver

Replying to er13:

p.s. Kannst Du bitte mal erklären, was Dir dieses "being on the bleeding edge" bringt?

Spaß am Ausprobieren und erster sein im Fehler melden nehme ich an. :-)

@dileks Freitag auf der uClibc-Mailingliste:

...
V=1 is quiet plus defines. V=2 are verbatim commands. I don't know (nor care)
what the kernel does for V=2 but if you want make to spit out dependency
decisions then just run make -d -p or something. Note that we do _not_ use
kbuild in uClibc, so please don't expect kbuild behaviour...

Liegt also nicht an Freetz, sondern an deiner uClibc-0.9.32.

comment:246 als Antwort auf: ↑ 245 Geändert vor 4 Jahren durch dileks

Replying to oliver: …

@dileks Freitag auf der uClibc-Mailingliste:

...
V=1 is quiet plus defines. V=2 are verbatim commands. I don't know (nor care)
what the kernel does for V=2 but if you want make to spit out dependency
decisions then just run make -d -p or something. Note that we do _not_ use
kbuild in uClibc, so please don't expect kbuild behaviour...

Liegt also nicht an Freetz, sondern an deiner uClibc-0.9.32.

Mir geht es nicht um Hexenjagd oder stets einen Schuldigen zu suchen, sondern Lösungen zu finden. Ja, die Email habe ich offline gelesen, da der Text a bissl truncated aussieht in [1] wohl das "V=2" übersehen. Ich habe entsprechende Änderungen in der uclibc.mk vorgenommen. Dann kann es ja weitergehen mit der Käferjagd. Danke für den Hinweis, Oliver.

[1] http://lists.uclibc.org/pipermail/uclibc/2011-March/045005.html

comment:247 Antwort: Geändert vor 4 Jahren durch er13

In [6796]:

binutils:

  • bump version to 2.21.51.0.8
  • remove unnecessary ARM and SuperH patches

uClibc:

  • fix build problems with binutils ≥ 2.21.51.0.7 (Error: .size expression for _init/_fini does not evaluate to a constant)

comment:248 Geändert vor 4 Jahren durch er13

In [6802]:

toolchain:

  • remove unnecessary ARM, Ubicom, and ColdFire patches
  • refs #842

comment:249 Geändert vor 4 Jahren durch er13

In [6834]:

toolchain:

  • add (preliminary) gcc-4.6.x support
  • refs #842

comment:250 Geändert vor 4 Jahren durch er13

In [6846]:

uClibc-0.9.29:

comment:251 Geändert vor 4 Jahren durch er13

In [6847]:

toolchain:

  • bump gcc-4.4.x version to 4.4.6
  • update download toolchains
  • refs #842

comment:252 als Antwort auf: ↑ 247 Geändert vor 3 Jahren durch dileks

Replying to er13:

In [6796]: binutils:

  • bump version to 2.21.51.0.8

Warum sind die 3 Revert-Patches notwendig?

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

comment:253 Geändert vor 3 Jahren durch er13

@dileks: der von der normalize-Funktion zurückgegebene Pointer zeigt in den meisten Fällen auf den neu allokierten Speicher. Es gibt aber Fälle, wo das nicht der Fall ist, der Pointer wird nur "geschoben", es wird nichts allokiert. Deswegen ist es falsch, den Speicher pauschal freizugeben (segfault). Reproduzierbar ist das Ganze mit uClibc-0.9.28. Mit dem 001.patch war ich wahrscheinlich etwas voreilig (lag aber daran, dass die Änderung vom selben Autor stammt).

Edit: ich muss noch ein testcase basteln und es upstream melden.

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:254 Geändert vor 3 Jahren durch dileks

for er13: "PR binutils/12720" (vgl. [1])

[1] http://sourceware.org/git/?p=binutils.git;a=commit;h=1df895fd7aefe1b4c0b4c77eb2cf14f6379e05d9

Wie von dir w.o. erwähnt, partieller revert. Heisst im Klartest diesen Commit verwenden, am besten noch mit "Add testcases for "ar -d" and "ar -m"." aus [2]:

[2] http://sourceware.org/git/?p=binutils.git;a=commit;h=1adb00b96747a3ce2d88c5813c2da5cd5e1df37d

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

comment:255 Antwort: Geändert vor 3 Jahren durch er13

@dileks: wollte gerade dieselben Links posten, aber Du warst etwas schneller ;-)

PR binutils/12720

comment:256 als Antwort auf: ↑ 255 ; Antwort: Geändert vor 3 Jahren durch dileks

Replying to er13:

@dileks: wollte gerade dieselben Links posten, aber Du warst etwas schneller ;-)

PR binutils/12720

Nimmst du den offiziellen Fix mit TestCase auf (s.w.o, anstelle der 3 Revert-Patches)?

comment:257 Geändert vor 3 Jahren durch dileks

uClibc und ELF size-directive Fixes für binutils (i386 und x86_64):

i386: fix .size of _init/_fini

x86_64: fix .size of _init/_fini

Patch von er13 kann man durch obige offizielle Patches auf uclibc/master ersetzen.

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

comment:258 Geändert vor 3 Jahren durch oliver

@dileks
Warum benötigen wir i386 und x86_64 Patches? Wir bauen uClibc für mips(el).

comment:259 als Antwort auf: ↑ 256 Geändert vor 3 Jahren durch er13

Replying to dileks:

Nimmst du den offiziellen Fix mit TestCase auf (s.w.o, anstelle der 3 Revert-Patches)?

Nein und zwar deswegen, weil mein Fix sich in keinster Weise von dem offiziellen Fix unterscheidet. Und nachdem wir kein make test ausführen, ist es auch wurscht, ob Testcases dabei sind oder nicht.

Patch von er13 kann man durch obige offizielle Patches auf uclibc/master ersetzen.

Ich habe den Eindruck, Du hast Dich nicht tief genug mit dem Problem auseinander gesetzt. Zum einen wie sollen die offiziellen Patches für i386/x86_64 das Problem für mips(el) lösen? Zum anderen, wo unterscheiden sich bitte schön meine Lösung und der offizielle Fix für i386/x86_64, oder sogar noch dreister ausgedrückt, siehst Du nur ein Zeichen, in dem sich die beiden Lösungen unterscheiden - ich nicht. Der einzige Unterschied, den ich erkennen kann, besteht darin, dass im Fall von i386/x86_64 es die .size-Direktive schon gegeben hat und im Fall von mips(el) hat diese gefehlt. Also gibt es aus meiner Sicht rein gar keinen Anlass irgendwas durch irgendwas zu ersetzen…

p.s. Ich würde Dich bitten, Dich etwas besser mit der Materie auseinander zu setzen, bevor Du irgendwas behauptest, aber vorallem uns Ratschläge gibst.

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:260 Geändert vor 3 Jahren durch oliver

In [6944]:

[labor_preview] download-toolchain: Update following files without version number bump:

  • mipsel_gcc-4.4.6-freetz-0.3-shared-glibc.tar.lzma (old was built for 64-bit)
  • mipsel_gcc-4.5.2_uClibc-0.9.31-freetz-0.3-shared-glibc.tar.lzma (pthread fixes)
  • mips_gcc-4.5.2_uClibc-0.9.31-freetz-0.3-shared-glibc.tar.lzma (pthread fixes)
  • delete old files in dl/-directory if you have trouble
  • refs #1233
  • refs #842

comment:261 Geändert vor 3 Jahren durch er13

In [7005]:

binutils:

  • bump version to 2.21.51.0.9
  • refs #842

comment:262 Geändert vor 3 Jahren durch er13

In [7006]:

gcc-4.5.x:

  • bump version to 4.5.3
  • refs #842

comment:263 Geändert vor 3 Jahren durch er13

In [7052]:

toolchain:

  • add a simple shell script that could be used to automate the download-toolchain generation process
  • refs #842

comment:264 Geändert vor 3 Jahren durch er13

In [7073]:

[labor_preview] build_download_toolchains script:

  • add labor versions support
  • refs #842

comment:265 Geändert vor 3 Jahren durch er13

In [7077]:

uClibc++:

  • add support of long long data types to istream class
  • add wchar support to istream/ostream classes
  • fix clean rule
  • refs #643
  • refs #842

comment:266 Geändert vor 3 Jahren durch er13

Neben uClibc-0.9.32 mit NPTL support wurde auch 0.9.31.1 released. Wollen wir unsere 0.9.31 auf 0.9.31.1 vor 1.2 updaten?

comment:267 Geändert vor 3 Jahren durch er13

Btw NPTL support: weiß jemand, ob Binaries die gegen uClibc mit clone-based threading support gelinkt wurden, neu übersetzt werden müssen, wenn man auf uClibc mit NPTL-based support umsteigt.

comment:268 Antwort: Geändert vor 3 Jahren durch oliver

Gegen ein Update von 0.9.31 auf 0.9.31.1 spricht nichts. Die meisten Änderungen haben wir schon als Patches (http://git.buildroot.net/uClibc/log/?h=0.9.31). uClibc-0.9.32 hat noch linuxthreads.old, aber da sollten wir erst testen in wie weit das noch funktioniert. Soweit ich das auf der uClibc-Mailingliste mitgelesen habe bräuchten wir für NPTL einen weiteren gcc-stage?

comment:269 als Antwort auf: ↑ 268 Geändert vor 3 Jahren durch dileks

Replying to oliver:

uClibc-0.9.32 hat noch linuxthreads.old, aber da sollten wir erst testen in wie weit das noch funktioniert.

Kombination aus gcc-4.5.3 + uClibc-0.9.32 (LINUXTHREADS_OLD=y) + binutils-2.21.52.0.1 funst hier.
Wichtig ist hierbei der 180er Patch für uClibc.
Kommt gcc-4.6 zum Einsatz gibts Backtrace beim dsld-Start (hier: W701V_7170).
(Vgl. auch Ticket #1310).

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

comment:270 Antwort: Geändert vor 3 Jahren durch dileks

"@all trunk users: Please remove -march=4kc from your .config and all lines containing ac_cv_env_CFLAGS or ac_cv_env_CXXFLAGS from your config.cache"

-FREETZ_TARGET_CFLAGS="-Os -pipe -march=4kc -Wa,--trap"
+FREETZ_TARGET_CFLAGS="-Os -pipe -Wa,--trap"

sd@seduxbox:/mnt/sdb3/freetz/freetz-trunk_r7120$ find ./ -name config.cache | wc -l
46

Which config.cache(s)?

comment:271 als Antwort auf: ↑ 270 Geändert vor 3 Jahren durch er13

Replying to dileks:

Which config.cache(s)?

$(FREETZ_BASE_DIR)/$(SOURCE_DIR)/config.cache

alle unter $(FREETZ_BASE_DIR)/$(SOURCE_DIR)/_config.cache-backup kannst Du ignorieren

comment:272 Geändert vor 3 Jahren durch er13

@oliver: bin gerade dabei uClibc auf 0.9.31.1 und binutils auf 2.21.52.0.2 upzudaten (just FYI, damit wir es nicht doppelt machen)

comment:273 Geändert vor 3 Jahren durch oliver

Ja danke, hatte auch gerade angefangen. Dann bau ich mal mit 0.9.32…

comment:274 Geändert vor 3 Jahren durch er13

In [7125]:

binutils:

  • bump version to 2.21.52.0.2
  • remove ld.bfd hardlink (cosmetic change)

uClibc:

  • bump uClibc-0.9.31.x to 0.9.31.1, remove patches made it upstream

gcc-4.5.3:

  • don't install python scripts (cosmetic change)

refs #842

p.s. new download toolchains are on the way

comment:275 Geändert vor 3 Jahren durch er13

In [7126]:

toolchains:

  • sync download toolchains with r7125
  • refs #842

comment:276 Geändert vor 3 Jahren durch dileks

Vorschlag: 100-Config.mips.patch (Erläuternder Text)

+config CONFIG_MIPS_ISA_MIPS32_4KC
+       bool "MIPS32 4KC (FRITZ!Box based on SoCs like AR7 or UR8)"
+
+config CONFIG_MIPS_ISA_MIPS32_24KC
+       bool "MIPS32 24KC (FRITZ!Box based on SoCs like AR9, IKS or VR9)"
+

Evtl. könnte man noch in toolchain/Config.die Blöcke für FREETZ_KERNEL_LAYOUT_* und die Einträge in "config FREETZ_KERNEL_LAYOUT" alphabetisch sortieren.

Geändert vor 3 Jahren durch oliver

So?

comment:277 Geändert vor 3 Jahren durch oliver

Welche Patches wolltest du noch wie umbenennen?

comment:278 Geändert vor 3 Jahren durch oliver

In [7130]:

  • cosmetic fixes (refs #842)

comment:279 Geändert vor 3 Jahren durch oliver

In [7131]:

  • uClibc: Rename some patches, add prefixes (refs #842)

comment:280 Geändert vor 3 Jahren durch dileks

@olistudent: Danke für r7130 und r7131.

Wie ich schon angeboten habe, sollte man bei allen Toolchain Patches die Herkunft prüfen und dokumentieren, ich hatte dir einen DEP-3 [1] Header vorgeschlagen (beim Konvertieren dpatch→quilt habe ich das für Debian's binutils schon mal gemacht.
Minimum DEP-3:

1. Description [ or Subject (required) ]
2. Origin [ (required except if Author is present) ]
3. Author [ or From (optional) ]

Credits wem Credits gebühren!
Ich müsste nur wissen, welche Patches Marke "Eigenbau" und welche von Dritten (z.B. OpenWRT) sind.
uClibc: 011 (Whoopie?), 100, 101 und 990 (er13) sind von freetz.
binutils: einige Patches von Debian und er13(?), gcc: Ein Patch von Thorsten Glaser, von er13(?) etc. ppp.
Wie auch schon in meiner PM angeregt: Einheitliche Namenskonvention (3-stelliger nummerischer Präfix), Fremd-Patches etvl. mit Suffix labeln, z.B. 410-llvm_workaround_openwrt.patch. Evtl. auch Kategorisierung dokumentieren: 100-110 (Configs?).
Soll ich da mal drüber schauen?

My 0.02EUR.

P.S.: Für "Author" Feld wäre Full Name + Email-Adresse nett (auch würde ich eine MAINTAINERS [2] Datei wie beim Linux-Kernel anregen, würde das freetz-Projekt transparenter machen).

[1] http://dep.debian.net/deps/dep3/
[2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=MAINTAINERS

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

comment:281 Antwort: Geändert vor 3 Jahren durch er13

@dileks: ja, hast Du Recht, all das wäre sinnvoll, bloß es fehlt uns die Zeit dafür ;-) (nicht ernst gemeint ;-))

Meine 2 cents zu der Benennung der Patches. Im Namen des Patches soll irgendwie das Problem widerspiegelt werden, welches mit dem Patch gelöst wird. Der Name der gepatchten Datei hat im Namen vom Patch selbst nichts zu suchen. Beispiel: 100-Config.mips.patch und 101-Rules.mak.patch gehören für mich zusammengefasst und umbenannt.

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:282 als Antwort auf: ↑ 281 Geändert vor 3 Jahren durch dileks

Replying to er13:

@dileks: ja, hast Du Recht, all das wäre sinnvoll, bloß es fehlt uns die Zeit dafür ;-) (nicht ernst gemeint ;-))

Wie gasagt… ich kann den Part übernehmen… bin aber ATM im IPv6 Fever.

Meine 2 cents zu der Benennung der Patches. Im Namen des Patches soll irgendwie das Problem widerspiegelt werden, welches mit dem Patch gelöst wird. Der Name der gepatchten Datei hat im Namen vom Patch selbst nichts zu suchen. Beispiel: 100-Config.mips.patch und 101-Rules.mak.patch gehören für mich zusammengefasst und umbenannt.

Einheitlich! ACK: 100 + 101 gehören zu einem Patch zusammengefasst.

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

Geändert vor 3 Jahren durch dileks

Refreshed 011 Patch for uClibc (0.9.32)

comment:283 Geändert vor 3 Jahren durch dileks

Attached refreshed 011 Patch (uClibc-0.9.32).

Geändert vor 3 Jahren durch dileks

Add MIPS32_4KC and MIPS32_24KC to target cpu arch (replaces 100+101 patches for uClibc)

comment:284 Geändert vor 3 Jahren durch er13

Der Name des Patches gefällt mir nicht ;-) Vorschlag: ipv6_defines_according_to_kernel_version

Und was den Text oben anbetrifft: in diesem konkreten Fall viel zu viel Prosa aus meiner Sicht, "based on xy.patch by Whoopie" würde reichen. Angesichts dessen, dass der Patch sehr einfach ist, wird derjenige, der sich den Patch anschaut, schon selbst in der Lage sein, Whoopie's und Deine Version zu vergleichen. Und bitte dreistellige Zahl als Prefix, ich meine sogar zweistellige würde reichen ;-)

Edit: auch beim zweiten Patch viel zu viel Prosa aus meiner Sicht: "consolidate as suggested by …" meine ich interessiert niemanden. Das einzig wichtige ist die Beschreibung des Problems, welches mit dem Patch gelöst wird. Alles andere nur dann, wenn der Patch von jemand anderem stammt, um rechtstechnisch sauber zu bleiben.

Zuletzt geändert vor 3 Jahren von er13 (vorher) (Diff)

comment:285 Geändert vor 3 Jahren durch dileks

Der erläuterndende Text beschreibt kurz & knapp was getan worden ist. Wen Referenz zu alten Patches besteht, wird das auch erwähnt. Ebenso Tested-by und Tested-against sind immer gern gesehen. Lieber mehr Text als zu wenig. Ich verfolge die Empfehlungen von [1].
Der Name des IPv6 Patches gefällt mir auch nicht. Ausserdem ist mir nicht ganz klar, ob *alle* Linux-kernels ⇐2.6.14 (bis runter zur welchen Version?) IPv6 und entsprechende Defines unterstützen. IPv6 ist Neuland für mich.

[1] http://who-t.blogspot.com/2009/12/on-commit-messages.html

P.S.: In verschiedenen Projekten ist es auch Usus Credits zu vergeben (was immer wieder vergessen wird).

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

comment:286 Geändert vor 3 Jahren durch er13

Ich hätte nichts dagegen, Deine Kommentare so wie sie jetzt in den Patches stehen in den freetz-commit-messages zu verwenden. In den Patches selbst haben sie jedoch aus meiner Sicht nichts zu suchen.

comment:287 Geändert vor 3 Jahren durch dileks

Die Kommentare sollten nach Einchecken ins SVN-Repository nicht verloren gehen. Ich arbeite gern mit GIT.

comment:288 Geändert vor 3 Jahren durch er13

Die Kommentare wie "patches consolidated as suggested by" gehören in die commit-message, die Beschreibung des adressierten Problems in den Patch selbst.

p.s. ich will Dich nicht wirklich demotivieren, aber am Ende mache ich es eher so, wie ich es für richtig halte (Betonung auf richtig und nur ein wenig auf ich ;-), ;-) und noch ein ;-)), es sei denn Du, oliver, sonst jemand überzeugen mich durch logische Argumente vom Gegenteil. Bisher ist es Dir nicht gelungen.

comment:289 Geändert vor 3 Jahren durch er13

In [7132]:

uClibc patches:

  • combine patches with fritzbox specific arch/tune flags into one
  • rename them to better reflect their purpose and origin
  • refs #842

comment:290 Geändert vor 3 Jahren durch er13

In [7136]:

  • don't treat libgcc_s as a special case, install it just like any other library
  • refs #842

comment:291 Antwort: Geändert vor 3 Jahren durch cuma

Ich bekomme diese Meldung, den Kommentar von r7119 hab ich beachtet

7270-freetz/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/bin-ccache/../lib/gcc/mipsel-linux-uclibc/4.4.6/../../../../mipsel-linux-uclibc/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory

Image für 7170 lies sich bauen, ist plötzlich aber 30KB zu groß, vorher war noch etwas Platz. Sind ein paar Pakete/libs größer geworden oder kommt da zuviel ins Image?
(Falls das nichts mit diesem Ticket zu tun hat, einfach löschen)

Zuletzt geändert vor 3 Jahren von cuma (vorher) (Diff)

comment:292 Geändert vor 3 Jahren durch oliver

Um welches Paket geht es denn? Hast du freetype mal neu gebaut?

comment:293 als Antwort auf: ↑ 291 Geändert vor 3 Jahren durch er13

Replying to cuma:

7270-freetz/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/bin-ccache/../lib/gcc/mipsel-linux-uclibc/4.4.6/../../../../mipsel-linux-uclibc/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory

könntest Du bitte dafür ein neues Ticket aufmachen und Deine .config anhängen

Image für 7170 lies sich bauen, ist plötzlich aber 30KB zu groß, vorher war noch etwas Platz. Sind ein paar Pakete/libs größer geworden oder kommt da zuviel ins Image?

Bei mir bei gleicher .config (kein neues Paket, kein Subopt umgestellt) ist das Image sogar minimal kleiner geworden (was auf die neue binutils-Version zurückzuführen ist). Bist Du Dir sicher, dass Du kein neues Paket dazu gewählt hast, es kann auch sein, dass aufgrund eines Version-Bumps ein oder anderes Paket größer geworden ist. Könntest Du das bitte verifizieren (um eben solche Vergleiche führen zu können, lösche ich meine alten Images erst paar Wochen später).

comment:294 Geändert vor 3 Jahren durch er13

In [7148]:

toolchain:

  • allow GNU libstdc++ to be used as the implementation of the Standard C++ Library. See CHANGELOG diff for more details.
  • refs #842

@all trunk users: Please replace all occurrences of g++-uc with g++-wrapper in $(FREETZ_BASE_DIR)/$(SOURCE_DIR)/config.cache and in $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/bin/libtool if you don't want to rebuild the whole world.

comment:295 Geändert vor 3 Jahren durch cuma

Der Fehler mit freetype kam beim rrdtool. Hab alles komplett neu gebaut, und es lief durch. War wohl irgendwo noch was gecacht. Alte Images hab ich keine mehr, hab zum neu bauen alles gelöscht -.-

comment:296 Geändert vor 3 Jahren durch cuma

Image für 7170 lies sich bauen, ist plötzlich aber 30KB zu groß, vorher war noch etwas Platz. Sind ein paar Pakete/libs größer geworden oder kommt da zuviel ins Image?

Zur Info, nach neuem Checkout & alter .config sind wieder 20 KB frei

comment:297 Geändert vor 3 Jahren durch er13

In [7162]:

toolchain:

  • fix the option "use GNU libstdc++ as Standard C++ Library" doesn't work if ccache is used (ccache: FATAL: Could not find compiler "mipsel-linux-uclibc-g++-wrapper" in PATH)
  • refs #842

comment:298 Geändert vor 3 Jahren durch oliver

In [7164]:

  • ccache: Bump to version 3.1.5
    • set default to n (developer feature)
    • refs #842

comment:299 Geändert vor 3 Jahren durch oliver

In [7171]:

  • toolchain: Add uClibc-0.9.32 (use linuxthread.old for now, no nptl support yet)
    • tested with 7270 labor preview (no problems occured)
    • refs #842

comment:300 Geändert vor 3 Jahren durch oliver

In [7172]:

  • Add missing patches (not ready yet) and .config for uClibc-0.9.32 (refs #842)

comment:301 Geändert vor 3 Jahren durch oliver

In [7173]:

  • Fix uClibc-0.9.32 patches (credits go to dileks)

Geändert vor 3 Jahren durch oliver

comment:302 Antwort: Geändert vor 3 Jahren durch oliver

@er13
Müssten die Abhängigkeiten nicht wie im Patch sein? Oder soll es darauf ankommen welche uClibc Version das AVM Image hat? Dann müsste die uClibc-0.9.32 Zeile entfernt werden.

comment:303 Geändert vor 3 Jahren durch Whoopie

Wenn uClibc 0.9.32 funktioniert, können wir dann 0.9.30 und 0.9.31 entfernen? Das würde Backports von Patches einfacher machen, da man nicht 5 Versionen überprüfen muss, ob ein Patch für diese Version notwendig ist.

comment:304 Geändert vor 3 Jahren durch oliver

Wir haben bisher die AVM uClibc-Version nicht geändert, außer der Benutzer hat das explizit gesetzt. Falls es keine Fehler gibt wäre das aber eine Überlegung wert.

comment:305 als Antwort auf: ↑ 302 Geändert vor 3 Jahren durch er13

Replying to oliver:

Müssten die Abhängigkeiten nicht wie im Patch sein?

Ja, so wie im Patch ist es richtig. Es kommt auf die gebaute Version an, nicht auf die in der original firmware.

comment:306 Geändert vor 3 Jahren durch oliver

In [7222]:

  • Fix toolchain/Config.in "reduced locale set" option

comment:307 Geändert vor 3 Jahren durch dileks

Jetzt weiss ich warum meine Toolchain-Tarballs so gross werden, ich baue ja mit ccache:

$ du -s -h toolchain/target/var/cache
31M        toolchain/target/var/cache

Könnte man in das Makefile eine Abfrage einbauen, wenn ccache verwendet wird, dann 1. vorher obiges cache-Verzeichnis löschen 2. Toolchain-Tarballs generieren?

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

comment:308 Geändert vor 3 Jahren durch er13

Es reicht nicht aus, das Verzeichnis zu löschen bzw. beim Tarball-Erstellen zu excluden, ccache muss auch noch deinstalliert werden (bin-ccache und alle Links). Sonst ist ccache immer an und die entsprechende Option hat keine Auswirkung.

Baue Dir die toolchain ohne ccache und schalte ccache erst dann ein, wenn Du die selbstgebaute Toolchain verwendest.

comment:309 Geändert vor 3 Jahren durch er13

In [7243]:

toolchain:

  • bump gcc 4.6.x version to 4.6.1
  • refs #842

comment:310 Geändert vor 3 Jahren durch dileks

gcc-4.6.1 bump…?

-FREETZ_GNULIBSTDCXX_VERSION="6.0.15"
+FREETZ_GNULIBSTDCXX_VERSION="6.0.16"

comment:311 Geändert vor 3 Jahren durch er13

In [7244]:

gcc-4.6 version bump in r7243:

  • fix libstdc++ version, thanks to dileks for pointing this out
  • refs #842

comment:312 Geändert vor 3 Jahren durch dileks

Für iptables-1.4.11.1 bräuchte man noch einen Upstream-Fix (vgl. #1393) für diverse uClibc-Versionen. Ich baue gerade nochmal mit den den 15 post-0.9.32 Patches. 990er Patch ist obsolet (partiell merged in 9990002-ctor-dtor-nptl-Fix-init-and-fini-function-compilatio.patch). Wenn jemand bei Gelegenheit auch mal auf #1310 schauen könnte (ltrace/libelf hunt started). Danke!

Geändert vor 3 Jahren durch dileks

List of post-0.9.32 uClibc patches (from 0.9.32 GIT branch)

comment:313 Geändert vor 3 Jahren durch dileks

Please, rename my patch to 011-ipv6_defines_according_to_kernel_version.patch and fire it up, Thanks.

comment:314 Geändert vor 3 Jahren durch dileks

I have here backported FREETZ_TARGET_GCC_SJLJ_EXCEPTIONS from OpenWrt, if you like I can provide a patch. C++, so :-).
Inspired by <https://dev.openwrt.org/changeset/27261>

comment:315 Geändert vor 3 Jahren durch er13

Und was hätten wir davon? Zumal es die Ursache dafür war, dass exception handling mit uClibc++ nicht funktioniert hat, s. r4898

comment:316 Geändert vor 3 Jahren durch dileks

Mir 88, gibt inzwischen noch eine andere C++ Lib.

comment:317 Geändert vor 3 Jahren durch er13

Nochmal, welchen Mehrwert bringt uns diese Option? Das, was wir jetzt haben, funktioniert mit beiden stdc++ libraries und sogar die openwrt-Kollegen schreiben: "Warning: increases code size and runtime memory usage."

comment:318 Geändert vor 3 Jahren durch dileks

Nochmal mir 88… und OpenWrt-Kollegen haben Option drin.

comment:319 Geändert vor 3 Jahren durch ralf

Bei openwrt ist es aber als Default aus, und ganz unten in dem Ticket steht, dass es nicht mehr gebraucht wird. Was also bringt es?

Zuletzt geändert vor 3 Jahren von ralf (vorher) (Diff)

comment:320 Geändert vor 3 Jahren durch er13

Ehrlich gesagt, weiß ich nicht, ob ich die Diskussion weiterführen soll. Wenn auf die Frage nach dem Mehrwert als Antwort "OpenWrt-Kollegen haben die Option drin" kommt, habe ich das Gefühl, dass ich mit einem Erstklässler rede…

Die haben eine Menge Optionen/Pakete drin, die wir nicht haben. Die Unterstützen auch viel mehr Plattformen als wir. Bei einer dieser Plattformen wird die Option wohl notwendig sein. Ist übrigens schlecht, dass die OpenWrt-Kollegen in ihrem commit-Message nichts dazu sagen, wann die Option einzuschalten wäre. Bis die Frage nach dem Mehrwert geklärt ist (für freetz meine ich gibt es keinen), eindeutiges Veto von mir.

comment:321 Geändert vor 3 Jahren durch dileks

Das war jetzt deine 2. Beleidigung…
"OpenWrt Kollegen" - was hast denn mit den Jungs schon ausgetauscht? Ich hab jüngst mit nbd (Felix Fietkau) über den ar7-Port und acx-mac80211 gesprochen. Den Cross-Community oder gar Community Gedanken hast du nicht verinnerlicht. Hättest du den verinnerlicht, hättest du 2-mal die Chance gehabt, BRs zu öffnen und Patches nach Upstream zu schicken. Bsp. #1 die 3 unkommentierten binutils Patches. Es musste erst doko (Matthias Klose, Debian Maintainer, mit dem hab ich mich auch schon ausgetauscht, siehe Changelog) 4-5 Wochen später drüber stolpern und im Gegensatz zu dir hat er ein BR geöffnet und ein Patch kam prompt nach Upstream. 2. verpasste Gelegenheit dein crt*.S Patch. Der wurde erst kürzlich nach uClibc upstream geschickt (folded in einen anderen Patch).

Google doch mal wer die Diskussion zw. binutils und Linux-kernel Developers angeregt hat und wie es zur entsprechenden Option gekommen ist, die beide Seiten befriedet hat. Schau auch mal wessen Patch zuerst in linux-next war, gesplittet wurde für 2.6.39.

Deine beleidigende Art darfst du unverzüglich ablegen! Willst du überhaupt mit Menschen zusammenarbeiten? Ich habe im IRC schon mehrmals angeregt, bei dem giftigen Ton, gerade im IPPF mal härter durchzugreifen.

OpenWrt hat die Option drin, weil jemand das Problem getracked hat, es haben wollte und einen Patch geliefert hat. Warum muss alles einen Mehrwert haben? Und Mehrwert für wen?

Für Diskussion haben wir im freetz Projekt IRC.

comment:322 Geändert vor 3 Jahren durch er13

Oh, jetzt werden wir persönlich, das ist definitiv nicht im Sinne von opensource-Community. Hiermit Schluss mit Diskussion hier. Ich werde im IRC Dir die Gelegenheit geben, all die Vorwürfe zu äußern und auch meine Antworten darauf zu erfahren…

comment:323 Geändert vor 3 Jahren durch er13

In [7249]:

toolchain/gcc-4.6.x:

  • add patch fixing gcc-4.6.x regression causing uClibc' old_atexit.c to be miscompiled (freetz-patch by dileks, upstream patch by Jakub Jelinek)
  • refs #1310, refs #842, refs #1396
  • thanks to dileks for testing

comment:324 Geändert vor 3 Jahren durch oliver

In [7251]:

[freetz-stable-1.2]: Merge in r7243:7244, r7248:7250 from trunk (refs #1396):


r7243 | er13 | 2011-07-02 17:53:25 +0200 (Sa, 02. Jul 2011) | 4 Zeilen
toolchain:

  • bump gcc 4.6.x version to 4.6.1
  • refs #842

r7244 | er13 | 2011-07-02 18:32:32 +0200 (Sa, 02. Jul 2011) | 4 Zeilen
gcc-4.6 version bump in r7243:

  • fix libstdc++ version, thanks to dileks for pointing this out
  • refs #842

r7248 | er13 | 2011-07-05 00:12:43 +0200 (Di, 05. Jul 2011) | 4 Zeilen
vsftpd:


r7249 | er13 | 2011-07-05 08:26:19 +0200 (Di, 05. Jul 2011) | 5 Zeilen
toolchain/gcc-4.6.x:

  • add patch fixing gcc-4.6.x regression causing uClibc' old_atexit.c to be miscompiled (freetz-patch by dileks, upstream patch by Jakub Jelinek)
  • refs #1310, refs #842
  • thanks to dileks for testing

r7250 | oliver | 2011-07-05 10:56:15 +0200 (Di, 05. Jul 2011) | 1 Zeile

  • build prerequisites: Remove jam, transmission doesn't depend on it anymore

  • r7242 needs more testing

Geändert vor 3 Jahren durch dileks

uClibc-0.9.32 patchset (freetz + post-0.9.32 from upstream)

comment:325 Geändert vor 3 Jahren durch er13

@dileks: mir sind es zu viele Patches. Ich würde da wirklich nur Fixes übernehmen (keine Weiterentwicklungen) und zwar nur Fixes, die für freetz relevant sind (9990008-libdl-search-for-ELF_RTYPE_CLASS_DLSYM-in-dlsym.patch oder NPTL-patcges gehören z.B. nicht dazu). Sonst ist es einfach zu viel Aufwand. Wenn Du "on the bleeding edge" sein möchtest, dann kannst Du 0.9.33git als Target einführen und als URL @git verwenden und dann musst Du die Patches nicht manuell einpflegen.

Geändert vor 3 Jahren durch dileks

v2: Renamed to 011-ipv6_defines_according_to_kernel_version.patch

comment:326 Geändert vor 3 Jahren durch oliver

In [7269]:

uClibc patch: (refs #842)
Enable IPv6 for Linux kernel smaller 2.6.14

This is a refreshed version of 011-ipv6_oldkernels.patch by Whoopie.

The patch was renamed to clearly indicate its function (as suggested by er13).

An identical include was removed and the include moved to top of file.
Some comments were added and the code was beautified a bit.

Tested IPv6 with my Speedport W 701V box based on v2.6.13.1 Linux-kernel.

Signed-off-by: Sedat Dilek <sedat.dilek@…>

comment:327 Geändert vor 3 Jahren durch er13

@Oliver: ich nehme mal an, Du möchtest noch einige Patches von dileks einchecken. Könntest Du bitte hier Bescheid geben, wenn Du mit allem, was Du planst fertig bist, damit ich die neuen download-toolchains bauen könnte. Danke!

Ich bin übrigens dafür folgende Patches einzuchecken und zu backportieren:

  • 990007-resolv-try-next-server-on-SERVFAIL.patch
  • 9990011-resolv-fix-bug-in-res_init-with-ipv6-nameservers.patch
  • 9990015-libc-add-missing-lock-initialization-in-vswprintf.patch
  • und vielleicht noch 9990005-Rules.mak-Rearrange-appending-UCLIBC_EXTRA_CFLAGS-to.patch

Alles andere ist aus meiner Sicht für freetz nicht relevant.

Geändert vor 3 Jahren durch oliver

comment:328 Geändert vor 3 Jahren durch oliver

@er13
Ich habe die vier vorgeschlagenen Patches versucht anzupassen. Mit älter werdender uClibc passen dann nur noch 3, 2 und schließlich einer davon. Ich kann nicht feststellen, ob ein Backport der fehlenden Patches notwendig ist.

Kompiliert habe ich damit auch noch nicht.

comment:329 Geändert vor 3 Jahren durch er13

In [7277]:

toolchain, gcc/binutils-makefiles:

  • ensure no docs, no man-pages, no NLS-files are built by hacking build-system a bit
  • noticeably speeds up the build-process, eliminates dependency on gettext and intltool
  • don't install gccbug script, it's not necessary, gcc-4.6.x doesn't even provide it
  • refs #842
  • refs #1396

comment:330 Geändert vor 3 Jahren durch er13

In [7300]:

uClibc-0.9.3x:

  • add some upstream patches, by dileks
  • refs #842, refs #1396

comment:331 Geändert vor 3 Jahren durch er13

In [7301]:

uClibc:

  • rename/reorder patches, fix offsets
  • refs #842

comment:332 Geändert vor 3 Jahren durch er13

In [7303]:

  • show full uClibc-version in menuconfig, refs #842

comment:333 Geändert vor 3 Jahren durch er13

In [7305]:

  • sync build_download_toolchains-script with the latest firmware version bumps
  • refs #842

comment:334 Geändert vor 3 Jahren durch er13

In [7306]:

download-toolchains:

comment:335 Geändert vor 3 Jahren durch oliver

In [7326]:

[freetz-stable-1.2]: Merge in r7242, r7254, r7256, r7258:7260, r7274, r7277, r7280, r7291, r7300:7303, r7310:7311, r7321, r7325 from trunk (refs #1396):


r7242 | oliver | 2011-07-02 13:50:06 +0200 (Sa, 02. Jul 2011) | 4 Zeilen

  • libfreetz: Update to version 0.5 (refs #61)
    • Fixes libfreetz for older firmwares: 2170, 3070, 3130, 3131, 3170, 7140
    • Should be merged to stable-branch if confirmed
    • by RalfFriedl

r7254 | oliver | 2011-07-05 15:02:57 +0200 (Di, 05. Jul 2011) | 2 Zeilen

  • 7112: Fix alien firmware (missed update)

r7256 | cinereous | 2011-07-05 15:26:46 +0200 (Di, 05. Jul 2011) | 1 Zeile

  • build-prerequisites: Add msgfmt to warnings, because building of binutils-kernel needs it

r7258 | oliver | 2011-07-05 17:13:13 +0200 (Di, 05. Jul 2011) | 1 Zeile

  • Callmonitor: Don't compile on $(pkg) target (nocompile target)

r7259 | oliver | 2011-07-05 17:57:00 +0200 (Di, 05. Jul 2011) | 2 Zeilen

  • openvpn: Some small fixes and improvements to "openvpn_conf" (refs #1129)
    • by MaxMuster

r7260 | oliver | 2011-07-05 19:39:33 +0200 (Di, 05. Jul 2011) | 2 Zeilen


r7274 | oliver | 2011-07-06 11:31:07 +0200 (Mi, 06. Jul 2011) | 1 Zeile
Config.in: FREETZ_TYPE_FON_5124 and FREETZ_TYPE_FON_5140 have AVM libcrypto and libssl


r7277 | er13 | 2011-07-07 08:36:26 +0200 (Do, 07. Jul 2011) | 7 Zeilen
toolchain, gcc/binutils-makefiles:

  • ensure no docs, no man-pages, no NLS-files are built by hacking build-system a bit
  • noticeably speeds up the build-process, eliminates dependency on gettext and intltool
  • don't install gccbug script, it's not necessary, gcc-4.6.x doesn't even provide it
  • refs #842

r7280 | er13 | 2011-07-07 08:50:38 +0200 (Do, 07. Jul 2011) | 3 Zeilen

  • remove dependency on msgfmt, from what I've tested we don't require it anymore

r7291 | oliver | 2011-07-08 11:20:08 +0200 (Fr, 08. Jul 2011) | 1 Zeile

  • Remove obsolete lines from W701V and W900V Alien patches

r7300 | er13 | 2011-07-09 23:31:21 +0200 (Sa, 09. Jul 2011) | 4 Zeilen
uClibc-0.9.3x:

  • add some upstream patches, by dileks
  • refs #842

r7301 | er13 | 2011-07-10 13:12:32 +0200 (So, 10. Jul 2011) | 4 Zeilen
uClibc:

  • rename/reorder patches, fix offsets
  • refs #842

r7302 | er13 | 2011-07-10 13:39:59 +0200 (So, 10. Jul 2011) | 3 Zeilen
freetz_patch, AUTO_FIX_PATCHES mode:

  • change "labels" of the patched files: include filename, omit .orig-suffix and timestamp

r7303 | er13 | 2011-07-10 13:44:57 +0200 (So, 10. Jul 2011) | 2 Zeilen

  • show full uClibc-version in menuconfig, refs #842

r7310 | oliver | 2011-07-11 12:06:36 +0200 (Mo, 11. Jul 2011) | 3 Zeilen

  • onlinechanged: Fix German Umlauts (by JMC)
    • Fix wording
  • fixes #1408

r7311 | oliver | 2011-07-11 12:18:24 +0200 (Mo, 11. Jul 2011) | 1 Zeile

  • Add 2 devices (/dev/ttyACM{0,1}) needed for USB CDC ACM (by adn77)

r7321 | oliver | 2011-07-12 00:43:26 +0200 (Di, 12. Jul 2011) | 1 Zeile

  • usbroot: Set unmount oldroot option default to 'no' because it sometimes causes problems

r7325 | cuma | 2011-07-12 14:14:04 +0200 (Di, 12. Jul 2011) | 1 Zeile
support file: lsmod, mount & /proc/partitions added (refs #1330)


comment:336 Geändert vor 3 Jahren durch er13

In [7427]:

toolchain:

  • introduce menuconfig option which allows to create a target toolchain compatible with unmodified firmware
  • refs #842

comment:337 Geändert vor 3 Jahren durch er13

In [7474]:

binutils (both kernel- & target-toolchains):

  • bump version to 2.21.53.0.2
  • refs #842

comment:338 Geändert vor 3 Jahren durch oliver

In [7503]:

  • uclibc: Don't strip libraries (refs #1160, #842)

comment:339 Geändert vor 3 Jahren durch er13

In [7543]:

gcc-4.4.x:

  • revise pr42980_backport.patch, split it into two separate patches (for better comprehensibility)

gcc-4.5.x/4.6.x:

  • add pr42980_backport.patch'es
  • expected to fix some parallel build problems reported on IRC

p.s. pr42980 is still not closed (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980)

comment:340 Geändert vor 3 Jahren durch oliver

In [7571]:

[freetz-stable-1.2]: Merge in r7534, r7540, r7543, r7553:7554, r7558, r7562:7563, r7567, r7570 from trunk (refs #1396):


r7534 | cuma | 2011-08-26 05:31:31 +0200 (Fr, 26. Aug 2011) | 1 Zeile
external: skip stopping during shutdown (speed up), rc.mod stops all packages


r7540 | oliver | 2011-08-27 10:59:27 +0200 (Sa, 27. Aug 2011) | 3 Zeilen


r7543 | er13 | 2011-08-27 19:48:19 +0200 (Sa, 27. Aug 2011) | 11 Zeilen
gcc-4.4.x:

  • revise pr42980_backport.patch, split it into two separate patches (for better comprehensibility)

gcc-4.5.x/4.6.x:

  • add pr42980_backport.patch'es
  • expected to fix some parallel build problems reported on IRC

p.s. pr42980 is still not closed (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980)


r7553 | er13 | 2011-08-28 23:59:21 +0200 (So, 28. Aug 2011) | 4 Zeilen
makefiles:

  • introduce a new helper function qstrip
  • use it to eliminate some code clones

r7554 | er13 | 2011-08-29 00:35:22 +0200 (Mo, 29. Aug 2011) | 4 Zeilen
build system:

  • abort build process with an error if user defined compiler flags (menuconfig:Advanced options/Toolchain options/Target compiler flags) contain CPU/arch related flags, these are automatically set by freetz build environment
  • refs #1465

r7558 | oliver | 2011-08-29 23:38:19 +0200 (Mo, 29. Aug 2011) | 1 Zeile

  • siproxd: Register as daemon

r7562 | er13 | 2011-08-31 00:20:30 +0200 (Mi, 31. Aug 2011) | 4 Zeilen
siproxd:


r7563 | er13 | 2011-08-31 01:30:18 +0200 (Mi, 31. Aug 2011) | 3 Zeilen
siproxd:

  • bump version to 0.8.1 (untested)

r7567 | er13 | 2011-09-01 23:07:42 +0200 (Do, 01. Sep 2011) | 4 Zeilen
tor:

  • bump version to 0.2.2.32 (by make)
  • fixes #1481

r7570 | buehmann | 2011-09-03 11:29:11 +0200 (Sa, 03. Sep 2011) | 4 Zeilen
callmonitor-1.19.2

The default "start type" has changed to "no". You may have to re-enable Callmonitor.


comment:341 Geändert vor 3 Jahren durch er13

In [7651]:

build_download_toolchains:

  • use 7270_V1 to build download toolchains for little-endian, uClibc-0.9.29 based boxes
  • refs #842, #1432

comment:342 Geändert vor 3 Jahren durch er13

In [7652]:

build_download_toolchains:

comment:343 Geändert vor 3 Jahren durch cuma

Gibt es hier akut für 1.2 noch was zu tun? Ansonsten verschiebt es doch bitte

comment:344 Geändert vor 3 Jahren durch oliver

  • Lösung auf fixed gesetzt
  • Status von assigned nach closed geändert

comment:345 Geändert vor 3 Jahren durch oliver

Fortsetzung für Freetz-1.3 in #1517.

comment:346 Geändert vor 3 Jahren durch oliver

In [7767]:

  • uClibc: Switch some options to be more like AVM
    • should fix non working mediaserver on 7270 and 7390
    • refs #842

comment:347 Geändert vor 8 Monaten durch ralf

In 11859:

  • uclibc hosttools
  • Fix portability issues: define TARGET_WORDSIZE, don't use host wordsize
  • only 0.2.29 at the moment
  • refs #842

comment:348 Geändert vor 8 Monaten durch ralf

In 11860:

  • uclibc hosttools
  • Fix ldd on 64-bit host for 0.9.32.1
  • refs #842

comment:349 Antwort: Geändert vor 8 Monaten durch er13

@Ralf: ist es beabsichtigt, dass an einer Stelle __WORDSIZE und an der anderen TARGET_WORDSIZE genutzt wird? Sieht vom Patch-Lesen her etwas komisch aus, davor wurde an beiden ELFCLASSM genutzt.

Ich würde an beiden Stellen TARGET_WORDSIZE verwenden und in der Headerdatei

#ifndef TARGET_WORDSIZE
#define TARGET_WORDSIZE __WORDSIZE
#endif

Sofern Du beabsichtigst, den Patch upstream zu submitten, so gibt es noch eine Stelle, wo ELFCLASSM referenziert wird.

comment:350 als Antwort auf: ↑ 349 ; Antwort: Geändert vor 8 Monaten durch ralf

Replying to er13:
Es ist nicht beabsichtigt. Den Block mit byteswap_to_host habe ich aus dem readelf.c von 0.9.29 kopiert, das gar nicht verändert wird.

Das grundsätzlich Problem ist, dass das Makefile zwar die Programme erstellen will, die auf dem Host laufen und für Programme des Targets funktionieren, aber die ELF Definitionen vom Host verwendet. Konkret ist das Makro ElfW() so definiert, dass es __ELF_NATIVE_CLASS verwendet, was wiederum auf __WORDSIZE definiert wird (bits/elfclass.h, bits/wordsize.h).

Speziell die Änderung für 0.9.29 ist nicht darauf ausgelegt, elegant zu sein, sondern möglichst wenig zu ändern. Deswegen auch die Datei link.h. Die Programme verwenden include "link.h", obwohl es keine lokale Datei mit dem Namen gibt, so dass die Datei vom System gelesen wird. Der Patch legt die Datei "link.h" an und liest selbst <link.h> ein. Nachdem dort Konstruktionen verwendet werden wie "makefile will include elf.h for us", braucht man sich keine großen Gedanken machen, ob das Ergebnis elegant ist oder nicht. Außerdem lohnt es sich wohl kaum, einen Patch für eine alte Version zu schicken.

Was das Senden eines Patches betrifft, ich bin nicht auf der Email Liste von uclibc. Die Patches sind eher auf minimale Änderungen als auf ein elegantes Ergebnis ausgelegt, und die neueste Version habe ich mir noch nicht einmal angeschaut. Zunächst mal wäre abzuklären, ob uclibc das überhaupt als Problem ansieht, das gelöst werden sollte. Wenn ich es richtig verstanden habe, hattest Du dort schon mal auf das Problem hingewiesen, und es ist nichts passiert? Wenn sie es ändern wollen, werden sie diese Änderungen eher als Ansatz nutzen und nicht als fertige Lösung.

Generell wird nicht nur ELFCLASSM definiert, sondern auch MATCH_MACHINE. Auch dieses sollte für das Target definiert werden und nicht für den Host. Ich weiß aber nicht, ob das uns betrifft.

Welche der Programme sind denn tatsächlich wichtig? Ich habe gesehen, dass es readelf in den neueren Versionen nicht mehr gibt, was auch nicht weiter schlimm ist, auf meinem System ist ein readelf dabei, das weitaus mehr kann und sowohl für 32 als auch 64 Bit Dateien verwendet werden kann.

Das wäre meiner Meinung nach der Vernünftige Ansatz, dass man Programme erstellt, nicht notwendigerweise als Bestandteil von uclibc, die mit allen ELF Dateien zurecht kommen. Den Ansatz von Busybox, für ldd die ELF Dateien zu lesen, finde ich auch besser als den vom GNU ldd, das Programm mit einer Environmentvariablen zu starten und zu hoffen, dass als Ergebnis nicht das Programm ausgeführt wird, sondern der Linker die Abhängigkeiten ausgibt.

Das geht aber über einen einfachen Patch hinaus.

comment:351 als Antwort auf: ↑ 350 ; Antwort: Geändert vor 8 Monaten durch er13

Replying to ralf:

Konkret ist das Makro ElfW() so definiert, dass es __ELF_NATIVE_CLASS verwendet, was wiederum auf __WORDSIZE definiert wird (bits/elfclass.h, bits/wordsize.h).

Das hatte ich vor mittlerweile 3-4 Jahren auch gesehen als ich versucht habe das Problem anzugehen. Deswegen wundert es mich, dass es mit Deiner "mini"-Anpassung funktioniert.

Zunächst mal wäre abzuklären, ob uclibc das überhaupt als Problem ansieht, das gelöst werden sollte. Wenn ich es richtig verstanden habe, hattest Du dort schon mal auf das Problem hingewiesen, und es ist nichts passiert?

Oliver hat im Oktober 2010 auf der uClibc-ML danach gefragt - es gab leider rein gar keine Reaktion, nachgehakt haben wir auch nicht. Daher keine Ahnung, ob sie es als Problem ansehen bzw. sich überhaupt dessen bewusst sind, dass es u.U. ein Problem gibt.

Welche der Programme sind denn tatsächlich wichtig? Ich habe gesehen, dass es readelf in den neueren Versionen nicht mehr gibt, was auch nicht weiter schlimm ist, auf meinem System ist ein readelf dabei, das weitaus mehr kann und sowohl für 32 als auch 64 Bit Dateien verwendet werden kann.

Es sind glaube ich insgesamt 3 hosttools: readelf, ldd, ldconfig. readelf ist bei den binutils dabei, daher fällt uClibc-readelf schon mal weg. ldconfig ist sehr spezifisch und ich glaube nicht, dass jemand es wirklich braucht, i.e. wir könnten problemlos darauf verzichten. Es bleibt nur noch ldd. Wenn es also irgendeine Alternative für ldd gäbe (Du schreibst was von busybox, ich habe jedoch kein ldd-Applet in busybox gefunden), so könnten wir uClibc-ldd durch das von busybox ersetzen und auf das Workarounden von uClibc-hosttools-Problemen gänzlich verzichten (i.e. Deine Patches wären dann weg, der entsprechende Teil des Makefiles auch und der dileks würde sich freuen, da er endlich eine reine 64-Bit Target Toolchain auf einem 64-Bit System hätte ;-)). Ich persönlich hätte nichts gegen so eine Lösung, sie wäre mir sogar lieber als die etwas dirty-Workarounds.

comment:352 als Antwort auf: ↑ 351 ; Antwort: Geändert vor 8 Monaten durch ralf

Replying to er13:

Du schreibst was von busybox, ich habe jedoch kein ldd-Applet in busybox gefunden

Ich meinte uclibc ldd.

Bei meiner Box sieht die Ausgabe von ldd.host ctlmgr so aus:

checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for '/lib/libpthread.so.0'
checking sub-depends for 'not found'
checking sub-depends for '/lib/libgcc_s.so.1'
checking sub-depends for 'not found'
checking sub-depends for '/lib/libc.so.6'
        libboxlib.so.0 => not found (0x00000000)
        libavmcipher.so.0 => not found (0x00000000)
        libavmhmac.so.2 => not found (0x00000000)
        libcm.so.0 => not found (0x00000000)
        libavm_event.so.1 => not found (0x00000000)
        libewnwled.so.1 => not found (0x00000000)
        libar7cfg.so.1 => not found (0x00000000)
        libjasonclient.so.0 => not found (0x00000000)
        libewnwnet.so.0 => not found (0x00000000)
        libwebsrv.so.2 => not found (0x00000000)
        libewnwlinux.so.2 => not found (0x00000000)
        libavmcsock.so.2 => not found (0x00000000)
        libwdt.so.1 => not found (0x00000000)
        libcrypt.so.0 => not found (0x00000000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00000000)
        libdl.so.0 => not found (0x00000000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000)
        libc.so.0 => not found (0x00000000)
        libc.so.6 => /lib/libc.so.6 (0x00000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

Da er auf dem Host sucht, findet er die meisten Libraries nicht, und die, die gefunden werden, gehören erst recht zum Host, daher kommt dann auch irgendwann libc.so.6 mit dazu, die es auf der Box gar nicht gäbe. Sinnvollerweise würde das Programm noch einen Pfad annehmen, in dem es Target Libraries sucht, aber das scheint nicht der Fall zu sein. Aber wenigstens gibt es eine Hilfe zu den Optionen:

ldd.host --help
Usage: ldd [OPTION]... FILE...
        --help          print this help and exit

Ein LD_LIBRARY_PATH wird zwar ausgewertet, aber den würde auch der Linker auf dem Host auswerten, auch der, der ldd.host startet. Generell scheinen die Host Tools nicht wirklich dafür ausgelegt zu sein, auf dem Host statt auf dem Target zu laufen.

dileks würde sich freuen, da er endlich eine reine 64-Bit Target Toolchain auf einem 64-Bit System hätte

Du kannst sicher sein, dass ich den Patch nicht wegen dileks gemacht habe.
Der Grund für den Patch ist natürlich, dass ich bei mir auf dem System keine 32-Bit Header habe. Das ist eigentlich kein Problem, aufgrund des Aufbaus der Makefiles wird einmal versucht, die Host Programme zu erstellen, das schlägt fehl, aber beim nächsten make wird nicht versucht, die Host Programme nochmal zu erstellen, von daher kein Problem, nur unschön. Um die Übersetzung neu anzustoßen, muss man zunächst toolchain/build/mips*_gcc-*_uClibc-*/mips*-linux-uclibc/usr/lib/libc.a entfernen.

Da ldd nicht davon abhängig ist, welche Version der uclibc man verwendet, könnten wir auch ein Programm auf Basis des neuesten uclibc ldd mit in die Tools aufnehmen. So wie es aussieht, tut sich da nicht viel, die Unterschiede zwischen 0.9.29 und 0.9.32.1 sind überschaubar.

comment:353 Geändert vor 8 Monaten durch er13

Bei mir funktioniert ldd.host nur, wenn ich LD_LIBRARY_PATH richtig setze:

checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libboxlib.so.0'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libavmcipher.so.0'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libavmhmac.so.2'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libcm.so.0'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libavm_event.so.1'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libled.so.1'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libewnwled.so.1'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libar7cfg.so.1'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libjasonclient.so.0'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libewnwnet.so.0'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libwebsrv.so.2'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libewnwlinux.so.2'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libavmcsock.so.2'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libwdt.so.1'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libpthread.so.0'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libdl.so.0'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libc.so.0'
checking sub-depends for '/home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libled2.so.2'
	libboxlib.so.0 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libboxlib.so.0 (0x00000000)
	libavmcipher.so.0 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libavmcipher.so.0 (0x00000000)
	libavmhmac.so.2 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libavmhmac.so.2 (0x00000000)
	libcm.so.0 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libcm.so.0 (0x00000000)
	libavm_event.so.1 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libavm_event.so.1 (0x00000000)
	libled.so.1 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libled.so.1 (0x00000000)
	libewnwled.so.1 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libewnwled.so.1 (0x00000000)
	libar7cfg.so.1 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libar7cfg.so.1 (0x00000000)
	libjasonclient.so.0 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libjasonclient.so.0 (0x00000000)
	libewnwnet.so.0 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libewnwnet.so.0 (0x00000000)
	libwebsrv.so.2 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libwebsrv.so.2 (0x00000000)
	libewnwlinux.so.2 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libewnwlinux.so.2 (0x00000000)
	libavmcsock.so.2 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libavmcsock.so.2 (0x00000000)
	libwdt.so.1 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libwdt.so.1 (0x00000000)
	libpthread.so.0 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libpthread.so.0 (0x00000000)
	libdl.so.0 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libdl.so.0 (0x00000000)
	libc.so.0 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libc.so.0 (0x00000000)
	libled2.so.2 => /home/gene/freetz/freetz-trunk-dev/build/modified/filesystem/lib/libled2.so.2 (0x00000000)
	not a dynamic executable

comment:354 als Antwort auf: ↑ 352 ; Antwort: Geändert vor 8 Monaten durch er13

Replying to ralf:

könnten wir auch ein Programm auf Basis des neuesten uclibc ldd mit in die Tools aufnehmen

Diesen Teil habe ich nicht ganz verstanden, daher wiederhole es so wie ich es verstanden habe. Sollte es nicht stimmen, bitte korrigieren ;-)

Du schlägst vor, dass wir auf Basis von ldd aus der allerletzten uClibc-Version ein neues (Host-)Paket machen, in dem der Fehler behoben/workaroundet ist, und dieses mit allen uClibc-Versionen mitausliefern. ldd aus uClibc selbst wird nicht mehr gebaut/verwendet. Ggf. könnte man es um den Parameter --sysroot erweitern und /usr/lib/freetz zu dem default-library-search-path hinzufügen, sodass das Setzen von LD_LIBRARY_PATH beim Aufruf von host.ldd nicht mehr notwendig wäre. Wenn ja, finde ich die Idee gut ;-)

comment:355 als Antwort auf: ↑ 354 Geändert vor 8 Monaten durch ralf

Replying to er13:

Du schlägst vor, dass wir auf Basis von ldd aus der allerletzten uClibc-Version ein neues (Host-)Paket machen, …

Genau das. Die Idee mit dem Root Path ist gut, und zusätzlich können wir eine Option für den Suchpfad hinzufügen. Das Verzeichnis /usr/lib/freetz sollte nicht notwendig sein, da ldd schon den rpath aus dem Programm holt. Ldd sollte (auch laut den Kommentaren im Programm) genauso suchen, wie es der dynamische Linker auch tut.

comment:356 Geändert vor 7 Monaten durch oliver

In 11875:

Fix patchlevel of hosttools patch (refs #842)

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