SPH-Toolchain für Ada, C, C++ (GCC 7.3.0 + uClibc-NG 1.0.28)

      SPH-Toolchain für Ada, C, C++ (GCC 7.3.0 + uClibc-NG 1.0.28)

      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:

      Quellcode

      1. CT_LINUX_VERSION="3.4.113"
      2. CT_BINUTILS_VERSION="2.30"
      3. CT_UCLIBC_NG_VERSION="1.0.28"
      4. CT_GCC_VERSION="7.3.0"
      5. CT_GMP_VERSION="6.1.2"
      6. CT_ISL_VERSION="0.18"
      7. CT_MPC_VERSION="1.1.0"
      8. CT_MPFR_VERSION="4.0.0"
      9. CT_LIBTOOL_VERSION="2.4.6"

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

      Quellcode

      1. mips-sph-linux-uclibc-addr2line
      2. mips-sph-linux-uclibc-ar
      3. mips-sph-linux-uclibc-as
      4. mips-sph-linux-uclibc-c++
      5. mips-sph-linux-uclibc-cc
      6. mips-sph-linux-uclibc-c++filt
      7. mips-sph-linux-uclibc-cpp
      8. mips-sph-linux-uclibc-ct-ng.config
      9. mips-sph-linux-uclibc-elfedit
      10. mips-sph-linux-uclibc-g++
      11. mips-sph-linux-uclibc-gcc
      12. mips-sph-linux-uclibc-gcc-7.3.0
      13. mips-sph-linux-uclibc-gcc-ar
      14. mips-sph-linux-uclibc-gcc-nm
      15. mips-sph-linux-uclibc-gcc-ranlib
      16. mips-sph-linux-uclibc-gcov
      17. mips-sph-linux-uclibc-gcov-dump
      18. mips-sph-linux-uclibc-gcov-tool
      19. mips-sph-linux-uclibc-gnat
      20. mips-sph-linux-uclibc-gnatbind
      21. mips-sph-linux-uclibc-gnatchop
      22. mips-sph-linux-uclibc-gnatclean
      23. mips-sph-linux-uclibc-gnatfind
      24. mips-sph-linux-uclibc-gnatgcc
      25. mips-sph-linux-uclibc-gnatkr
      26. mips-sph-linux-uclibc-gnatlink
      27. mips-sph-linux-uclibc-gnatls
      28. mips-sph-linux-uclibc-gnatmake
      29. mips-sph-linux-uclibc-gnatname
      30. mips-sph-linux-uclibc-gnatprep
      31. mips-sph-linux-uclibc-gnatxref
      32. mips-sph-linux-uclibc-gprof
      33. mips-sph-linux-uclibc-ld
      34. mips-sph-linux-uclibc-ld.bfd
      35. mips-sph-linux-uclibc-ldd
      36. mips-sph-linux-uclibc-nm
      37. mips-sph-linux-uclibc-objcopy
      38. mips-sph-linux-uclibc-objdump
      39. mips-sph-linux-uclibc-populate
      40. mips-sph-linux-uclibc-ranlib
      41. mips-sph-linux-uclibc-readelf
      42. mips-sph-linux-uclibc-size
      43. mips-sph-linux-uclibc-strings
      44. mips-sph-linux-uclibc-strip


      Hoffe, ihr habt Spaß damit und seid produktiv :D

      mfg, emkay

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

        (135,2 MB, 422 mal heruntergeladen, zuletzt: )
      Ich nochmal :D

      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 :D )

      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 :D )
      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++ :D
      --> sie könnte also nach und nach noch wachsen ;)

      mfg, emkay
      Dateien
      moin emkay,

      könntest du uns ein kurzes howto geben, wie man die toolchain benutzt? vielleicht anhand eines praktischen beispiels z.B. github.com/rvoicilas/inotify-tools?
      (die inotify sachen wären gut für scripte und führen einen befehl aus sobald sich eine datei ändert (sehr praktisch für scripte die fw regeln nach addresswechsel anpassen müssen)
      ich weiss wie ich software für meinen rechner kompiliere (./configure; make) aber mir ist nicht klar wie ich dem configure beibringe für eine ganz andere architektur zu kompilieren und die compiler auch aus deiner toolchain zu nehmen und nicht aus meinem system. chroot? kurzes praktisches beispiel wäre super!
      Moin @mchack!

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

      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 :D

      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... :D
      (EDIT: oder IP-Adresse...)

      mfg, emkay

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „eMKay77“ ()

      wow. hab deine sehr coole antwort gerade gelesen und muss jetzt aber leider gleich in die arbeit. Wollte nur schonmal danke sagen und ich guck's mir an Y1 war mir tatsächlich das wichtigste weil ich ja vermutlich mehr als nur ein tool portieren möchte. Y3 ist auch sehr interessant. diese ganzen internals des SPH sind mir noch sehr unklar (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.)
      Danke jedenfalls für die ausführlichen antworten :D

      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 :D

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

      mfg, emkay