Download-Toolchain mit GCC 4.2.1 im Selbstbau

[dileks]

Package auswählen in Menuconfig bzw. Add-On installieren. Dann einfach

make

Hannibal Lector: "Simplicity, simplicity, simplicity."

 

[Darkyputz]

moin dileks...
wie gross iss denn nun deine TC geworden?
und magst du die zum "rumtesten" mal irgendwo ablegen?
würde die gern versuchen...habe nur leider keine zig gig mehr zum compilen frei...
danke im voraus, auch wenn es nicht klappen sollte..

 

[dileks]

[1] Disk-Space

sd@elivebox[~/src/dsmod26_toolchain]$ du -s -h *toolchain*
14M kernel-toolchain-dsmod_gcc-3.4.5-glibc-2.3.6_20070809~sd.1.tar.lzma
4,0K kernel-toolchain-dsmod_gcc-3.4.5-glibc-2.3.6_20070809~sd.1.tar.lzma.md5sum
21M target-toolchain-dsmod_gcc-4.2.1-uClibc-0.9.28_20070809~sd.1.tar.lzma
4,0K target-toolchain-dsmod_gcc-4.2.1-uClibc-0.9.28_20070809~sd.1.tar.lzma.md5sum

[2] Test and Upload

Schön, dass sich jemand zum Testen bereit erklärt.
Upload wird etwas schwierig bzw. langsam by DSL-6000.
Gibt es nicht die Möglichkeit einer der zahlreichen dsmod-Mirrors zu nutzen (z.B. dsmod.magenbrot.net)? Das Archiv dort kann man "browsen".
Müsste man mit dem Mirror-Betreiber klären.

[3] A propos MD5SUM

Eine Anregung von mir wäre Prüfsummen für die dsmod-Pakete einzuführen. Da muss man kein Paranoiker sein ;-).

 

[olistudent]

Die Download-Toolchains des dsmod sind statisch kompiliert um Probleme mit verschiedenen Glibc-Versionen zu vermeiden. Wie es sich mit 64-Bit Systemen verhält weiß ich nicht. Dazu gabs noch kein Feedback. Wenn ich Zeit dazu habe, dann gibt es ein Update auf gcc-4.2.1.

MfG Oliver

 

[RalfFriedl]

Die Download-Toolchain läuft problemlos auf 64-Bit Systemen.

Ansonsten hätten sich bestimmt schon Leute gemeldet.

 

[dileks]

Die Download-Toolchain läuft problemlos auf 64-Bit Systemen.

Ansonsten hätten sich bestimmt schon Leute gemeldet.

Ohne eine akademische Diskussion vom Zaune zu reissen, sollte bitte nicht mehr die Rede von der "Download-Toolchain" (DTC) sein.
Bitte unterscheiden zwischen kernel-toolchain (KTC) und target-toolchain (TTC).

Eine Anregung zum Thema:
Es sollte doch möglich sein im menu-config zu hinterlegen:

1. Option (graue Theorie):
* lokale TTC/KTC zu verwenden (FileName) unter der Prämisse, dass es als LZMA-Archiv _und_ im dl-Verzeichnis vorliegen muss, z.B. "target-toolchain-dsmod_myversion.tar.lzma".

2. Option:
* Source-URL/Source-File für TTC/KTC auswählbar machen, z.B. könnte man die LZMA-Archiv via lokalem Web-Server zugänglich machen. Hierbei müsste nur die Angaben für SRC_URL (z.B. http://localhost/toolchain/) und SRC_FILE (my_TTC.lzma) eingetragen werden.

Verwendet man nicht die offiziellen KTC/TTC, gibt es trotz untergejubbeltem TTC eine Fehlermeldung, da der "Versions-String" nicht korrekt ist, Abhilfe ist ein SymLink darauf.

cd ~/src/ds26-15.2/toolchain/build
ln -sf gcc-4.2.1-uClibc-0.9.28 gcc-4.2.0-uClibc-0.9.28

Sinnvoller wäre es, die TTC testweise zu entpacken und sich den Pfadnamen zu holen.

Alles wäre einfacher, wenn man die DTC (Ooops) der Maintainer verwenden würde, böser dileks, böser.

 

[RalfFriedl]

Die Toolchain besteht aus Kernel-Toolchain und Userspace-Toolchain. Target ist ja beides, insofern ist das Verzeichnis toolchain/target etwas unglücklich benannt.
Die Download-Toolchain enthält beide Bestandteile, ebenso wie die selbst erstellt, weil ja beide gebraucht werden. (Auf die Kernel-Toolchain könnte man verzichten, solange man weder einen Kernel noch Module erstellen will.)

Option 1 ist nicht graue Theorie sondern ganz einfach: Du legst Deine Toolchain in dl/target-toolchain-dsmod-0.4.tar.lzma ab, und der ds-mod wird sie auspacken und verwenden, ohne zu wissen, daß es nicht seine eigene ist.

Zu Option 2 kannst Du in toolchain/make/download-toolchain.mk Name und URL eintragen, und es sollte auch gehen.

 

[dileks]

- Update -
ErrMsg mit reingenommen.

-dileks

Option 1 ist nicht graue Theorie sondern ganz einfach: Du legst Deine Toolchain in dl/target-toolchain-dsmod-0.4.tar.lzma ab, und der ds-mod wird sie auspacken und verwenden, ohne zu wissen, daß es nicht seine eigene ist.

Es geht so nicht, ich habs wirklich - nicht nur in grauer Theorie - schon so ausprobiert.
Irgendwo scheint der "Versions-String" (das Verzeichnis unterhalb toolchain/build) hinterlegt zu sein, daher die Abhilfe via SymLink. Wenn ich mich recht entsinne war die Fehlermeldung ".installed" not found (die Symlinks zu KTC/TTC im toolchain-Verzeichnis werden so wohl geprüft).

Genaue ErrMsg in Posting #17:
...
touch: kann „toolchain/target/.installed“ nicht berühren: Datei oder Verzeichnis nicht gefunden
make: *** [toolchain/target/.installed] Fehler 1
...

Zu Option 2 kannst Du in toolchain/make/download-toolchain.mk Name und URL eintragen, und es sollte auch gehen.

Yepp, that's the information I wanted - not yet tested.

Frage: Maintains du die TTC/KTC-Quellen?

Zur Namensgebung:
Irgendwelche Namen müssen wir den Freunden schon geben, aussagekräftigere Namen fallen mir nicht ein, aber warum nicht am Usage festhalten:
kernel-toolchain (usage: optionally to build the kernel) und package-toolchain (usage: to got those packages compiled).

 

[RalfFriedl]

Ich habe mit der Toolchain nichts zu tun.
Oliver schreibt ja, "Wenn ich Zeit dazu habe, dann gibt es ein Update auf gcc-4.2.1."

 

[dileks]

Ich habe mit der Toolchain nichts zu tun.
Oliver schreibt ja, "Wenn ich Zeit dazu habe, dann gibt es ein Update auf gcc-4.2.1."

Eine TTC basierend auf gcc-4.2.1/uclibc-0.9.28 gibt es doch schon -> von mir aus dem menuconfig kreiert und steht als ca. 21 MByte grosses LZMA-Archiv zur Verfügung.
Meine W701V läuft mit einer daraus erstellten Firmware.

Hat das Core-Team kein Vertrauen in Fremdhilfe?
Es wäre doch auch eine Zeitersparnis für das Core-Team.
Die TTC ist fertig, muss nur getestet und freigegeben werden.
Ich habe ja schon angeboten, es auf ein dsmod-Mirror hochzuladen.
Bisher keine Reaktion, Schade.

 

[olistudent]

Ich habe doch geschrieben, dass die Toolchains statisch kompiliert sein sollten. Sind das? Wohl nicht, oder? Außerdem gibt es ein paar Optionen zu beachten, wie z.B. LFS, g++, ccache usw.

MfG Oliver

 

[dileks]

Ich habe doch geschrieben, dass die Toolchains statisch kompiliert sein sollten. Sind das? Wohl nicht, oder? Außerdem gibt es ein paar Optionen zu beachten, wie z.B. LFS, g++, ccache usw.

MfG Oliver

Antwort, prompt:

sd@elivebox[~/src/dsmod26_toolchain/gcc-4.2.1-uClibc-0.9.28/mipsel-linux-uclibc/bin]$ ldd mipsel-linux-g++
linux-gate.so.1 => (0xb7f7d000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7e38000)
/lib/ld-linux.so.2 (0xb7f7e000)

 

[dileks]

...dass die Toolchains statisch kompiliert sein sollten...

Da Debian etch eine "betagte" glibc-2.3.6 als C-Bibliothek verwendet, sehe ich das als ein kleineres Problem, wenn die Programme dynamisch gelinked sind.

Anregung für den nächsten dsmod-Release:
Advanced Options -> Compiler Options -> Toolchains (Build toolchain (requires 4GB diskspace)) -> Target compiler flags

Im Hilfetext ein Hinweis darauf wie die Variable "DS_TARGET_CFLAGS" zu setzen ist, wenn man seine TTC statisch gelinked haben möchte.

 

[kriegaex]

Wozu sollte sich jemand eine statisch gelinkte TC bauen, wenn er nicht Entwickler ist und sie zum Download anbieten will? Schiebst Du Deine TC wohl öfter auf andere Linux-Rechner mit unterschiedlicher Konfiguration? Ich dachte immer, Du arbeitest in einer VM, und die kannst Du überall installieren, wo Du willst.

 

[dileks]

Wozu sollte sich jemand eine statisch gelinkte TC bauen, wenn er nicht Entwickler ist und sie zum Download anbieten will? Schiebst Du Deine TC wohl öfter auf andere Linux-Rechner mit unterschiedlicher Konfiguration?

Es liegt ein Missverständnis vor:
Meine TTC ist dynamisch gelinkt, was mir völlig ausreicht (s.w.o).
Kompatible C-Libs sollte sich auf jedem aktuellen Linux-System finden.
Oli wollte es unbedingt statisch.

Ich dachte immer, Du arbeitest in einer VM, und die kannst Du überall installieren, wo Du willst.

Im Moment arbeite ich nicht in einer VM, da ich iwlwifi (iwl3945) ausprobiere.
Die WLAN-Unterstützung wollte ich doch mal live testen.

 

[RalfFriedl]

Ich hab noch ein System mit glibc 2.3.4, also älter als Deine 2.3.6.
Deine Toolchain reicht Dir völlig aus. Sie sollte ja auch zu Deinem System passen.
Oliver wollte die Toolchain statisch, und er hat recht damit, weil die dann wirklich auf jedem System läuft. Wenn er jetzt Deine Toolchain für glibc 2.3.6 zum Download anbieten würde, kämen die Anfragen wegen nicht laufender Toolchain ja auch bei ihm an und nicht bei Dir. (Nein, von mit käme keine derartig Frage, ich bekomme das schon noch hin. Ich habe inzwischen auch eine Toolchain mit gcc 4.2.1, LFS und IPV6.)

Alexander hat Dich darauf hingewiesen, daß die vorgeschlagene Option "Target compiler flags" (um eine statische Toolchain zu erstellen) nur für sehr wenige Anwender sinnvoll ist.

Da sehe ich kein Mißverständnis.

Für die überwiegende Anzahl der Anwender tut es die Download Toolchain. Wer sie nicht will, kann sich einfach eine andere erstellen. Die fertige Toolchain braucht noch nicht einmal übermäßig viel Platz, bei mir ca. 350MB.

Wenn man von vorne anfangen will, kann man die Toolchain sichern und dann wiederherstellen. Oder man löscht gleich nur die Verzeichnisse source und packages.

 

[dileks]

Alexander hat Dich darauf hingewiesen, daß die vorgeschlagene Option "Target compiler flags" (um eine statische Toolchain zu erstellen) nur für sehr wenige Anwender sinnvoll ist.

Ein Hinweis, um die "Target Compiler Flags" statisch gelinked zu übersetzen sollte daher auch nur im Hilfstext erscheinen. Wer es dennoch gerne machen möchte, kann sich die Informationen dort per Cut-N-Paste rausziehen.

Nur so als Goodie gemeint.

 

[kriegaex]

Laßt uns doch alle einfach das Thema ad acta legen, und jeder macht sein Ding, wie er möchte. Dileks' Engagement, uns helfen zu wollen (auch wenn er eine andere TC baut, als wir sie benötigen, um sie zum Download zur Verfügung zu stellen), ist aller Ehren wert, nur nützt es in diesem Fall wenig. Würde eine Toolchain mit 4.2.1 irgendwelche bekannten Vorteile gegenüber 4.2.0 bringen oder Fehler beseitigen, hätte Oliver bestimmt bereits eine erstellt und zum Download freigegeben. Das kommt irgendwann auch, wie er ja bereits ankündigte, ist aber nicht dringend, weil es, wie gesagt, keinen Vorteil bringt. Die Idee, einen Satz Compiler-Flags dafür in den Hilfetext zu schreiben, finde ich dennoch gut, sofern es mit denen an dieser zentralen Stelle getan ist. Ich glaube nicht, daß es jemandem außer den Mod-Entwicklern selbst groß etwas bringt, aber eine schnelle Copy&Paste-Quelle zu haben, wenn man selbst mal Hand anlegt, schadet ja auch nicht, und es wäre eine Art kleinder Doku, wie die Download-TC gebaut wurde.

Edit: So, aber ein anderes Forschungsobjekt hätte ich für Dich, dileks: Es wurde dort gefragt:

Wozu laedt crosstool einen 2.6.8er Kernel runter (Backen der dsmod toolchain (8mb-26)?

Die Frage hatte ich bereits beantwortet (einfach im Thread weiter lesen), aber es wäre ja immerhin interessant zu wissen, ob man einen funktionierenden Kernel 2.6.13.1, der zu den AVM-Binaries paßt bzw. Module, die zu den Original-AVM-Kernels passen, über crosstool auch mit einer anderen Kombination von Kernel-Sourcen (z.B. ebenfalls 2.6.13) bauen kann, evtl. auch mit einer anderen Kombination von GCC, Binutils und glibc - idealerweise die gcc-4.2.1 und binutils-2.17.50.0.17, genau wie bei der Target- bzw. Userspace-TC. Null Ahnung, ob das technisch möglich ist bzw. woran es liegt, falls es nicht geht, aber da kann sich der geneigte Compilerbastler doch mal austoben. ;-)

Erleuchtet mich, ich liebe es, dazu zu lernen!

 

[dileks]

Gestern musste ich doch sehr mit dem Kopf schütteln.
Die ganze Diskussion um die Toolchain-Sache war doch sehr schwierig.
Angefangen schon bei der Namensvergabe.
Ein bisschen erinnerte es mich an die User, die gerne intensiver am dsmod mitarbeiten wollen und sich ausgeschlossen fühlen.
So Leut verliert man dann eher, die für die Weiterentwicklung hilfreich sein könnten.
Ich hatte bei der ganzen Diskussion auch das Gefühl, dass man es nicht möchte, "das Ruder aus der Hand zu geben".
Ja, man behandelt den dsmod zu sehr wie ein "rohes Ei".
Wer nicht weiss, was er da macht, kann physischen Schaden an seiner Box verursachen, ist immer gewarnt worden.
Ich persönlich fühle mich nicht von der Entwicklung ausgeschlossen, um das mal klar zu stellen.

Wenn man sich die Open-Source-Bewegung so ansieht, kommen auch "politische" Entscheidungen hinzu. Jüngst die Sache um den neuen CPU-Scheduler, bei dem Ingo Molnars cfs-scheduler den Vorrang vor Con Kolivas staircase deadline cpu scheduler bekam.
Resultat Con Colivas hat sich aus der Kernel-Entwickler-Gemeinde zurückgezogen. Was ich menschlich durchaus verstehen kann.

Ich lasse mich auf meinem Weg nicht beirren - auch wenn es manchmal mehr nach einer technischen Studie oder Machbarkeit aussieht.
Das weiter und tiefer Bohren in die Materie, hängt ein wenig mit meiner Lehre & Forschung Vergangeheit zusammen.
Solange es solche Menschen - mit intrinsischer Motivation - nicht gibt, wird es auch keine Spezialisten geben.

Dennoch Danke für "dein friedliches Fazit" und Schlichtungversuch.
Von mir wird es zu diesem Thema keinen weiteren Beitrag geben.

 

[olistudent]

@dileks
Über die Namensvergabe können wir uns unterhalten. Wenn du einen Vorschlag hast der "besser" ist, dann baue ich den gerne ein. Wie ich dir gestern erklärt habe ist deine Toolchain für uns nicht zu verwenden. Einen Schalter für eine statische Toolchain im dsmod fände ich aber gar nicht schlecht. Ich hab nämlich schon wieder vergessen wie das ging und muss das erst nochmal zusammensuchen.

@Alexander
Mit einigen Patches lässt sich der Kernel auch mit gcc-4.x.x bauen. Aber die gcc-Version sollte die gleiche sein wie die der Kernel-Module. Und AVM benutzt einen gcc-3.4.6, deshalb benutzen wir einen gcc-3.4.5. Spblinux hatte mich darauf aufmerksam gemacht. Dazu gibt es auch einen Thread. 3.4.6 ist im crosstool nicht drin.

MfG Oliver