Download-Toolchain mit GCC 4.2.1 im Selbstbau

[dileks]

"besser" ---> "aussagekräftiger"

"Kernel Toolchain" ---> dsmod-kernel-[cross|toolchain]
"Target Toolchain" ---> dsmod-mipsel-[cross|toolchain]

Freuen würde ich mich noch, wenn endlich die Packages/AddOns auf den dsmod-Mirrors eine MD5-Prüfsummen-Datei begleiten würde.
Seitdem ich eine Knoppix-Iso-Image verwendet habe, die nicht vollständig heruntergeladen wurde, habe ich mir das angewöhnt.

A propos Namenskonvention:
Wer Spass hat kann sich mal die Namen der Packages/AddOns durchsehen.
---> keine einheitliche Linie
---> Packages, die ein Update erfahren haben, bekommen den Namen der vorhergehenden Version (ohne Namen zu nennen, ich les schon mit)

A propos toochain:
http://people.debian.org/~ths/toolchain/sources.list
http://people.debian.org/~ths/toolchain/current-etch/etch-mipsel-cross/
http://people.debian.org/~ths/toolchain/current-sid/sid-mipsel-cross/

P.S.:
Mir geht es beim dsmod nicht darum, die User hier zu belehren oder mit meinem Fachwissen zu triumphieren: der dsmod soll noch ausgereifter werden, das ist mein Ziel, was mich hier im Forum mitarbeiten lässt.
In der Software-Entwicklung gibt es so manch Standards, die sinnvoll sind und auch im dsmod Verwendung finden sollten.

 

[kriegaex]

Gestern musste ich doch sehr mit dem Kopf schütteln

Und ich jetzt gerade, denn hier gibt es doch wieder einiges klarzustellen, das ich nicht so auf mir sitzen lassen kann.

Die ganze Diskussion um die Toolchain-Sache war doch sehr schwierig.
Angefangen schon bei der Namensvergabe.

Es ging doch zunächst gar nicht um die Namensvergabe, also hat nichts damit angefangen, das kam später.

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".

Das ist völliger Quatsch. Ich fasse mal zusammen, was Du getan hast:

• Menuconfig nicht richtig angeschaut und nicht verstanden, was es mit Download- und Build-Toolchains auf sich hat.
• Eigene TCs gebaut, dabei wild herum gepatcht, anstatt einfach Menuconfig zu benutzen, wo man alles bequem einstellen kann.
• Das Ergebnis versuchtest Du uns dann als Deine neue Version der Download-TC zu verkaufen, obwohl wir Dir erklärt haben, daß sie erstens nicht richtig gelinkt ist (dynamisch statt statisch) und somit nicht bei allen funktioniert und daß sie zweitens sowieso nicht nötig ist. Außerdem kann olistudent jederzeit eine neue erstellen ohne Deine ganze Hackerei.
• Wenn Du an einem Open-Source-Projekt mitarbeiten willst, ist das willkommen. Beispiel RoyceMcKnight. Er hat sich informiert, sinnvolle Beiträge geliefert und auch mal eine Frage gestellt und darf seit einigen Monaten einchecken, auch wenn er es selten tut. Was Du hingegen tust, ist, Dir einzubilden, Du wüßtest alles bereits (und selbstverständlich besser als wir). Deshalb machst Du Dir einen Haufen unnötiger Arbeit für etwas für unsere Zwecke Unbenutzbares.
• Daß Du dabei noch oberlehrerhaft behauptest, unsere Namensvergabe für die TCs sei falsch und müsse unbedingt geändert werden, macht es uns nicht leichter, Dich mit offenen Armen zu empfangen. Meine Meinung zu den beiden orthogonal laufenden Kategorien von Namen ist die: Download- vs. Build-TC sind gute Namen, die intuitiv beschreiben, worin sich die Versionen unterscheiden. Die andere Kategorie ist die Unterscheidung in das, was wir Kernel- und Target-TC nennen - Begriffe, die im Forum leider seit Jahren vorgeprägt sind und nicht einfach so geändert werden können, ohne Mißverständnisse auszulösen. Hier schlägst Du Kernel- vs. Userspace-TC vor, was ohne Zweifel sachlich richtig und besser ist, weil, wie wir zustimmen, "Target" verwirren kann, weil ja der Kernel auch fürs Target-System ist. Aber was hängt alles an so einer kleinen Änderung? Ist es damit getan, in Menuconfig zwei Strings zu ändern? Nein. Wir müßten die Leute im Forum auf die neue Nomenklatur "umschulen", indem wir sie konsequent benutzen. Dazu wäre es nötig, diverse häufig gelesene Threads nachträglich zu ändern, das Wiki umzuschreiben und zigmal die Frage zu beantworten, wieso wir plötzlich andere Begriffe verwenden als vorher. Dann kommt noch das Umbenennen von Make-Targets hinzu, das konsequenterweise der neuen Nomenklatur folgen müßte. Evtl. wäre es gut, so ein "Rebranding" zu machen, wie die Industrie es immer wieder vorführt: Raider heißt jetzt Twix, und viele andere Produktnamen haben sich auch geändert, aber meistens stand noch für mehrere Jahre der alte Namen mit dabei: Erst der neue klein neben dem alten, dann der neue größer als der alte, irgendwann nur noch der neue. Sowas mußt geplant sein, das geht nicht hauruck.
• Wie wäre es besser gegangen? Du hättest einfach mal fragen können, wie wir die Download-TC bauen, bevor zu anfängst herumzupatchen, zu experimentieren und uns zu drängen, Dein Resultat zum Download für alle bereitzustellen, obwohl es gar nicht bei allen läuft (dynamisch gelinkt, wie gesagt). Oliver hätte Dir nach Ende seines Urlaubs geantwortet (ich hätte nicht gewußt, wie er das immer macht, weil ich mich nie darum gekümmert habe), Du hättest loslegen und eine 4.2.1-Download-TC analog zu unserer 4.2.0-Version bauen können. Aber sie auf die Mirrors zu laden, würde trotzdem wenig bringen, weil man Menuconfig patchen müßte, um sie zu verwenden. Du siehst ja, daß,anders als bei der Build-TC, die Version der Download-TC fest verdrahtet ist. Das kann man ja mal änderbar machen, dann ist so eine Aktion auch leichter möglich.
• Mitarbeit im DS-Mod ist gern gesehen. Was glaubst Du wohl, wieviele Pakete drin sind, nur weil sie uns jemand geschickt hat? Aber was war Dein Beitrag bisher? Nichts Neues, keine Verbesserung. Nur eine in einer anderen GCC-Version gebaute TC, die als Download für alle nicht taugt. Und selbst wenn sie es täte, würde die 4.2.1 kein Problem lösen und nichts uns Bekanntes verbessern. Blindleistung nennt man sowas.

Also nächstes Mal bitte erst mal fragen, wie und wozu, bevor Du loslegst und Dich wunderst, daß wir nicht alle hurra schreien, weil es gelungen ist, eine dynamisch gelinkte TC mit GCC-4.2.1 zu bauen, was jeder andere über simple Auswahl der Version in Menuconfig auch hinkriegt.

Wenn man sich die Open-Source-Bewegung so ansieht, kommen auch "politische" Entscheidungen hinzu. Jüngst die Sache um den neuen CPU-Scheduler (...)

Irrelevant und hat nichts mit dem DS-Mod zu tun. Wir sind nicht "die" Open-Source-Bewegung, sondern ein kleines Sandkorn darin. Daß Verbesserungen bei uns langsamer gehen als bei anderen Projekten, kann daran liegen, daß wir im wesentlichen zu zweit sind momentan. Wir entscheiden auch nicht politisch, sondern nach Möglichkeit sachlich.

Ich lasse mich auf meinem Weg nicht beirren - auch wenn es manchmal mehr nach einer technischen Studie oder Machbarkeit aussieht.

Das ist ja okay, aber dann zwing uns nicht Dein Ergebnis auf. Außerdem ist Deine Machbarkeitsstudie in diesem Fall Blindleistung, wie gesagt. 4.2.1-TC ist auswählbar im Menü, und die richtigen Compilerschalter herauszufinden für eine passende Download-TC, kann olistudent helfen.

Edit und P.S.: Ich hatte Dir in meinem voringen Posting ein Forschungsobjekt zum Austoben mit echtem Nutzen vorgeschlagen, aber Du bist mit keinem Wort darauf eingegangen. Nur Oliver hat etwas dazu geschrieben.

 

[dileks]

Hallo Alexander,

dein Gemütsausbruch erinnert mich an die berüchtigte heftige (auch emotionale) Auseinadersetzung zwischenen Linux Torvalds und Prof. Tanenbaum in Sachen Linux vs. Minix.

Ich kann natürlich verstehen, dass du dsmod, an dem inzwischen federführend mitarbeitest, "verteidigst".
Gegen eine sachliche Diskussion habe ich keine Einwände, aber einige Ãusserungen sind sehr persönlich und gehören nicht in ein Forum.

In Torvalds Biographie "Just for Fun" ist zum Thema eine nette Anekdote zu lesen.
Jahre später hat Torvalds einen Vortrag in den Niederlanden.
Er sucht Prof. Tanenbaum in den Büroräumen der Uni Amsterdam auf, um eine persönliche Widmung in sein Exemplar des "Betriebs
ysteme" Buches (Autor Tanenbaum) zu bekommen, mit dessen Hilfe er "Linux" geschaffen hat. Prof. Tanenbaum war an diesem Tage nicht in seinem Büro.
Eine nette Anekdote..

Nun, zu deinen Ãusserungen:
(1) Gefrimmel?
Ein Synonym für dsmod verstehe ich als "FritzBox-Hacking".
Daher ist ein "Hack" nicht nur als "Gefrimmel" zu verstehen, sondern auch als elegante, zeitnahe Lösung eines Problems.
Dass man weiss, wo man Hand anlegen muss, zeigt mir, dass die Leut ihr Handwerk verstehen.

(2) Begrifflichkeiten/Namensvergabe/Namenskonvention?
Wie man in den knapp 40 Postings nachlesen kann, verstehen die Leut in Sachen "Download-Toolchain", etwas anderes oder unterscheiden nicht klar.
Das ist IMHO jetzt geklärt.

(3) Aufzwingen?
Falsch!
Es war in erster Linie ein Feedback, dass eine eigene TTC durch den Build-Prozess sauber durchläuft.
Zweitens, ist immer von einem Angebot die Rede gewesen.
Da sehe ich nirgends einen Zwang.
Wer zwingt dich denn Package/Addon xyz zu verwenden oder auf ein Posting zu antworten.
Niemand, ich auch nicht.

(4) Meisterleistung?
Wer hat das behauptet?
Ich habe die Bereitschaft wie viele andere im IPPF-Forum dazu zu lernen.
Wissen ist nicht begrenzt. Meines auch nicht.

(5) Sturrheit/Wortkargheit/Mitmachen
Ich hätte mich gerne bereit erklärt auch eine statische Version zu bauen.
Mir ist der Unterschied zw. dynamisch/statisch gelinked'ter Software klar, für andere kann ich nicht sprechen.
Man wollte selber eine bauen.
Dass Oli im Urlaub ist, war mir nicht bekannt.
Ich wollte auch niemanden bedrängen, schon garnicht im Urlaub.

(6) Wissen geht verloren!
Wie war das noch einmal eine statische TTC zu bauen?
Bei so vielen Baustellen muss man das halt nochmal nachlesen.
Ich erinnere mich dunkel, dass ich dass in WeHaveMoreFun/OpenWRT gelesen habe.
Auch ich beschäftige mich mit vielen Dingen.
Wichtig ist es die Erkenntnisse zu dokumentieren.
Das bestätigt mich in meinem Anstoss.

(7) Anregungen angekommen!
Wie man in diesem Thread nachlesen kann, haben ein paar Anregungen von mir die Leut aufgeweckt.

Fazit:
Die Gemüter beruhigen, das Wetter ist so schön draussen und ich sitze vorm PC. Mein Angebot steht immer noch.

Gruss,
Sedat

 

[dileks]

Neue KTC-0.2 und TTC-0.5

FYI:
olistudent hat beide Toolchains aktualisiert (vgl. [1] und [2]):
1. target-toolchain-dsmod-0.5.tar.lzma
2. kernel-toolchain-dsmod-0.2.tar.lzma

Die Binaries sind statisch gelinked übersetzt worden, hier zur Demonstration gcc-4.2.1-binary in der TTC-0.5:

sd@seduxbox:~/src/ds26-15.2/toolchain/build/gcc-4.2.1-uClibc-0.9.28/mipsel-linux-uclibc/bin$ ldd mipsel-linux-uclibc-gcc-4.2.1
not a dynamic executable

Hab heute mit beiden neuen TCs (KTC-0.2/TTC-0.5) eine neue Firmware-/Kernel-Image gebaut und verwende diese bereits.

Als Workaround für ds26-15.2:
1. Im dl-Verzeichnis KTC/TTC umbenennen.
2. Bei Programmabbruch in toolchain/build sysmbolische Links erzeugen und mit 'make' den Build fortsetzen (hier 2-mal notwendig: KTC/TTC).

# cd dl
# cp kernel-toolchain-dsmod-0.2.tar.lzma kernel-toolchain-dsmod-0.1.tar.lzma
# cp target-toolchain-dsmod-0.5.tar.lzma target-toolchain-dsmod-0.4.tar.lzma

>>> Build-Abbruch #1 (KTC) <<<
# cd toolchain/build
# ln -sf gcc-3.4.6-glibc-2.3.6 gcc-3.4.5-glibc-2.3.6
>>> Build-Abbruch #2 (TTC) <<<
# cd toolchain/build
# ln -sf gcc-4.2.1-uClibc-0.9.28 gcc-4.2.0-uClibc-0.9.28

Mein Replaced kernel sieht wie folgt aus:

/var/mod/root $ cat /proc/version
Linux version 2.6.13.1-ohio (sd@seduxbox) (gcc version 3.4.6) #1 Sat Aug 25 10:36:33 CEST 2007

Ein besonderes Dankeschön an olistudent.

WEB-LINKS:
[1] http://dsmod.magenbrot.net/target-toolchain-dsmod-0.5.tar.lzma
[2] http://dsmod.magenbrot.net/kernel-toolchain-dsmod-0.2.tar.lzma

 

[olistudent]

Dann scheint der Kernel also zu laufen? Sehr schön, den neuen gcc-3.4.6 hatte bis jetzt nämlich noch keiner getestet.

MfG Oliver

 

[dileks]

Dann scheint der Kernel also zu laufen? Sehr schön, den neuen gcc-3.4.6 hatte bis jetzt nämlich noch keiner getestet.

Einen kleinen Schönheitsfehler sehe ich gerade in der dsmod-UI.
Scheint ein Lokalisierungsproblem zu sein:

$(lang de:"Flash-Speicher (TFFS) für Konfigurationsdaten" en:"Flash memory (TFFS) for configuration data")

Der Button für die TFFS-CleanUp ist wie folgt beschriftet "$(lang de:".
Closing Parenthesis missing?

 

[kriegaex]

Es ist alles in Ordnung mit den Buttons bei mir. Nicht hacken, sondern svn update, und wie privat gesagt: Bitte nicht mehr öffentlich über interne Entwicklerversionen reden und schon gar keine Patches dafür veröffentlichen, die noch dazu unnötig sind, weil im SVN schon alles paßt. Dafür war Dein Zugang nicht gedacht. Alle anderen verwirrt es nur.

Edit: Da die Frage auch nichts mehr mit der Toolchain zu tun hat, schließe ich jetzt diesen Thread. Alles Sinnvolle und Sinnlose dazu ist, glaube ich, von allen Beteiligten gesagt worden.