Moin Leutz!

Da es nich in die Webdisk passt (ich darf so große Dateien dort nicht mehr posten...)

Ich habe mal eine aktualisierte Toolchain passend für den SPH gebaut:
Die bei Ubuntu direkt verfügbaren Toolchains linken precompiled Libraries zum fertigen Programm und da diese für einen 'höheren' MIPS-Befehlssatz vorkompiliert sind, heben sie das Binary auch auf diesen höheren Level, wodurch der SPH sie dann abweist.... deshalb (und weil ich Ada-Unterstützung wollte), habe ich selbst eine gebaut.

Ist also ein Ada, C, C++ Compiler auf aktuellem Stand, welcher passend zum SPH als Target 'MIPS32 - Version 1' hat.

-- Allerdings hab ich mich dazu entschieden, die neue uClibc-NG zu nutzen, statt der Version, welche auf dem SPH genutzt wird...
(die 'alte' uClibc wird seit Jahren nicht mehr weiter entwickelt - fand ich einfach keine gute Idee)
---> bedeutet, man sollte die neue uClibc-NG entweder auf dem SPH mit integrieren - oder einfacher - die uClibc-NG statisch mit einlinken.
---> persönlich kompiliere ich für den SPH eh meist komplett statisch, was mit der uClibc-NG auch problemlos funktioniert...
(im Gegensatz zu einer Glibc - die macht da gern Probleme)

Die Tools der Toolchain selbst hab ich statisch gelinkt - sollten also auf jedem Linux-x86_64 laufen.

In dem angehängten 'zip' ist ein 'tar.xz' --> einfach entpacken und den '/bin'-Ordner im Toolchain-Ordner in den Pfad aufnehmen.
Alle Binaries sind 'prefixed' mit der Toolchain-Kennung -->

Hoffe, ihr habt Spaß damit und seid produktiv

mfg, emkay

EDIT: bevor sich jemand beschwert --> alle Quellen sind unverändert - Quelltexte und Lizenzbedingungen sind jeweils auf den Projekt-Webseiten zu bekommen.

Ich nochmal

Ich habe da jetzt mal gnoga-1.2b in meine Toolchain integriert...

Gnoga ist ein GUI-Toolkit für Ada -- cross-platform.
Gnoga 'streamt' die GUI in Echtzeit in einen Webbrowser oder eine Webview - und da das sowohl lokal, als auch über LAN, als auch über's Internet funktioniert - ist es für headless Devices wie einen Server oder eben einen Router ziemlich cool... (und ziemlich einfach zu nutzen ist es auch )

Das Ganze ist dann nicht webseiten-basiert, sondern Events (Mouse-Move, Click, ...) rufen direkt den eigenen Code auf und eigener Code kann zB. in Echtzeit in den Browser / die Webview zeichnen...
Dabei läuft also kein Java-Script im Browser, sondern das Binary läuft auf dem Router - nur die GUI ist im Browser.
Man braucht dafür kein HTML oder JS -- alles pur in Ada.
(wobei man sowohl HTML5 als auch JS injizieren kann, wenn man will)

Da es für fast alle Plattformen Webbrowser gibt oder zumindest eine Webview und man GNAT (GCC-Ada) auch für nahezu jede Plattform bauen kann - läuft der selbe Code dann ohne Änderungen auf fast allen Plattformen

Ein nettes Beispiel wäre da die Anzeige oder Einstellung von den System-Parametern des SPHs in Echtzeit - auf PC, Smartphones, Tablets....
(ohne, daß dafür auf dem Endgerät zusätzliche Software installiert werden muß - Browser reicht)

Leider ist Gnoga für Ada only -- und Ada ist nicht jedermanns Sache (warum auch immer )
Aber wer noch eine Sprache lernen will, dem würd' ich Ada gern' an's Herz legen...
(ich war früher voll auf C/C++ -- aber Ada macht so Vieles besser und weit eleganter)
--> schon die Standard-Bibliotheken der Sprache und zusätzlich die erweiterten Standard-Bibliotheken des Compilers - alles cross-plattform - sind diese Überlegung wert.
(es gibt zB. mit gnat.expect eine recht schöne Möglichkeit, um andere Programme fernzusteuern und deren Ausgaben per RegEx auszuwerten -- wenn man damit zB. xdslcmd auf dem SPH steuert und die Ergebnisse dann per Gnoga visualisiert...)

Naja, ich dachte mir, ich habe die 'neue' Toolchain ja eh, dann kann ich sie auch teilen
-- auch wenn es vielleicht nicht für viele interessant ist.

Überhaupt kann man in eine solche Toolchain im Grunde beliebige vorkompillierte Bibliotheken integrieren - auch für C oder C++
--> sie könnte also nach und nach noch wachsen

mfg, emkay

Moin @mchack!

Ist halt ein X/Y-Problem: Du stellst Frage X, meinst aber Frage Y

Frage X: wie nutzt man die Toolchain?
Antwort X: wie jede andere GCC-Standalone-Toolchain auch
Man nutzt den Compiler aus der Toolchain und dieser ist vorkonfiguriert, so daß er automatisch auch die richtigen anderen Tools, Libraries und Parameter etc. nutzt.
--- ist aber nicht wirklich Deine Frage

Frage Y1: Wie nutz man 'configure' mit der Toolchain?
Antwort Y1: gute Frage...
Das mit dem configure ist ein Pseudo-Standard - leider sind nicht alle configure-Scripts gleich.
Wenn das Script nicht komplett verpfuscht ist, reicht es oft schon, dem configure auf den richtigen Compiler zu stuppsen - sicherer ist, dem Script auch die wichtigsten anderen Tools vorzugeben. Dafür gibt's mehrere Wege... ich bevorzuge den über Umgebungsvariablen.
('CC'-->C-Compiler, 'CPP'-->C-Präprozessor, 'LD'-->Linker, 'AS'-->Assembler, etc.)
Wenn Du 'configure --help' aufrufst, wird Dir alles angezeigt, was man dem Script 'unterschieben' kann - normlerweise reicht C-Compiler, Präprozessor, Linker, eventuell noch C++-Compiler und Assembler.
Im Grunde also einfach die Toolchain in den Pfad, passende Umgebungsvariablen setzen welche jeweils den Pfad zum Binary beinhalten -- dann configure aufrufen und es sollte die richtige Toolchain nutzen. Das resultierende Makefile sollte dann, wenn alles geklappt hat, für den SPH sein.

Frage Y2: kann man / kann ich für Dich inotify-tools auf den SPH portieren?
Antwort Y2: Richtig gute Frage... die Inotify-Tools benötigen Kernel-Unterstützung und ob der SPH die hat, kann ich nicht genau sagen.
Ausgehend von der Kenel-Version sollte er, aber sowas kann man konfigurieren. Ich selbst werde da aber nichts unternehmen, weil ich keine Verwendung dafür habe. (sowas 'verpflechted' das eigene Ziel sehr mit dem vorhanden System - was ich lieber vermeide. )

Frage Y3: könnte man inotify nutzen, um Änderungen an den Firewall-Regeln zu erkennen...
EDIT: seh' grad' - Du willst auf Adress-Wechsel reagieren --> Antwort ist aber die Selbe :D
Antwort Y3: eher nicht!
Inotify reagiert auf Änderunden an Dateisystem-Einträgen (INodes) -- aber nur eingeschränkt auf Enträge in /proc oder /sys.
Die entsprechenden Einträge / Dateien in /var legt der SPH bei Bedarf an - teilweise nur, wenn man bestimmte Seiten der GUI aufruft - eignen sich also nicht wirklich... manuelles Prüfen per 'ip address' oder Ähnlichem zB. einmal pro Sekunde dürfte da besser / sauberer sein

Am ehesten würde Dir wohl die Antwort auf Frage Y3 was bringen
Oder sogar Y4: wie triggert man am elegantesten eine Reaktion auf die Änderung der Routing-Table...
(EDIT: oder IP-Adresse...)

mfg, emkay

mchack schrieb:

(ich dachte tatsächlich an die datei /var/dhcp6c_ipaddrPre6 und /var/dhcp6c_ipaddr6 die anscheinend immer den aktuellen Prefix/ aktuelle Inet6 addresse des br0 interfaces hat - ob da erst was im GUI angestossen werden muss nach addresswechsel hatte ich noch nicht probiert.)

wie gesagt - ich bin da immer gegen zu viele Abhängigkeiten... aber wann/ob die Dateien aktualisiert werden, erfährst Du eventuell in der dazu gehörigen Dokumentatiion
dhcp6c ist ja ein standard Linux-Tool, da gibt's 'ne Doku und Man-Pages zu

Im einfachsten Fall reicht es vielleicht schon, eine Prüfsumme (CRC32/MD5...) von den Dateien zu machen, wenn die sich ändert --> TRIGGER

mfg, emkay