-fharden-compares
-fharden-conditional-branches
-fharden-control-flow-redundancy
-ftrivial-auto-var-init=zeroWer Firmware für Mikrocontroller baut, braucht einen Cross-Compiler. Den bekommt man mit crosstool-ng, als ARM-Download oder aus dem Paketmanager der Distribution. Das funktioniert — und wenn man dann noch Unit-Tests in der CI haben will, wird es richtig spannend.
Denn dann braucht man zwei Toolchains: eine für das Target
(arm-none-eabi-gcc mit newlib) und eine für den Host (x86_64
oder aarch64), mit der man denselben Code gegen ein Test-Framework
kompiliert. Auf dem Host läuft natürlich eine andere libc — aber
GCC-Generation, Google-Test-Version, gcov und die
Analyse-Werkzeuge müssen auf Punkt und Komma zusammenpassen.
Bare-Metal klingt dabei nach wenig Aufwand: Wenn newlib schon das Maß der Dinge ist, ist der Horizont quasi anfassbar. Die Herausforderung steckt nicht in der Menge der Abhängigkeiten, sondern darin, dass die Werkzeuge drumherum für Target und Host aus einem Guss sein müssen. Genau das lässt sich elegant lösen.
Nehmen wir an, der Cross-Compiler ist ein GCC 15 mit newlib. Die Unit-Tests laufen auf dem CI-Host, also brauchen wir dort ebenfalls einen GCC 15 — nicht den GCC 14, den Fedora 43 mitbringt, und schon gar nicht den GCC 13 aus dem Ubuntu-LTS der CI-Runner.
Dazu kommen ABI-gekoppelte Werkzeuge:
Google Test / GMock — kompiliert gegen die jeweilige Toolchain
gcov / lcov — müssen zur GCC-Version passen, sonst stimmt die Coverage nicht
valgrind — muss die ABI der getesteten Binaries verstehen
Wenn man das manuell pflegt, landen Target- und Host-Toolchain schnell in getrennten Beschaffungsketten. Das muss nicht sein.
Vor einigen Jahren bei einem Telekommunikationsausrüster: Ein SoM mit Netzwerk-Beschleunigern, dazu ein Binary-SDK vom Chip-Hersteller. 32-Bit, eine uralte GCC-Version, gelinkt gegen eine Linux-Distribution, die es nur noch auf dem Schwarzmarkt gegen Kamele gab. Lange bevor LLVM/Clang als ernstzunehmende GCC-Konkurrenz die Stagnation aufmischte.
Die IT betrieb dafür einen Multiprozessor-Knoten mit rund 64 VMs — je 2 VCPUs, 2 GB RAM, komplett überbucht, kaum wartbar. Das SDK ließ sich nicht reproduzieren, nicht aktualisieren und nicht auf eine andere Host-Plattform portieren. Dabei war der Chip sogar Linux-fähig — da wäre deutlich mehr gegangen.
Das Muster habe ich seitdem mehrfach gesehen: Chip-Hersteller wollen Chips verkaufen, keine Entwicklungsumgebungen. Das SDK ist Beiwerk — es erleichtert den Einstieg, soll aber nicht langfristig tragen. Ein Hersteller-BSP auf LTS-Basis, jahrelang gut genug — und wenn der LTS-Zyklus ausläuft, heißt es: Updaten, in sechs Wochen liefern, nichts darf kosten.
Das hat mich motiviert, einen anderen Weg zu gehen.
Das Yocto Project ist primär als Build-System für Embedded-Linux-Distributionen bekannt. Aber sein Rezept-System kann mehr: Es baut beliebige Toolchains aus den Quellen — und zwar für verschiedene Zielarchitekturen aus denselben Rezepten.
Der Schlüssel ist die MACHINE-Variable. Dieselben Rezepte für GCC,
newlib, Google Test und gcov erzeugen je nach Target:
| MACHINE | Ergebnis | Beispiel |
|---|---|---|
|
|
Mess-MCU, ADC-Frontend |
|
|
Kommunikations-MCU, DCP-Stack |
|
|
Kamera-Steuerung |
|
|
RISC-V IoT, Wi-Fi/BLE |
|
|
RISC-V mit DSP-Erweiterungen, atomthreads |
|
Host-nativer GCC derselben Generation |
CI: Unit-Tests, valgrind, Coverage |
Die Liste ließe sich fortsetzen. Der Punkt ist: Ob ARM Cortex-M, RISC-V oder Host-nativ — die Rezepte sind dieselben. Nur MACHINE und die zugehörige
Tune-Konfiguration unterscheiden sich.
Eine Quelle, eine GCC-Version, eine ABI-Kopplung — DRY und SSOT statt n getrennt gepflegte Toolchains.
Yocto baut dabei nicht nur den Compiler: Auch ein QEMU für das jeweilige Target lässt sich aus denselben Rezepten erzeugen. Damit kann man Firmware-Binaries auf dem CI-Host emulieren — ohne echte Hardware, aber mit der richtigen CPU-Emulation. Für Integrationstests auf einem Cortex-M oder RISC-V ist das Gold wert.
Die erste Intuition ist: Nur der Compiler und seine unmittelbaren Abhängigkeiten. In der Praxis zieht man die Grenze weiter.
Aus Yocto — eingefroren und versioniert:
GCC + binutils + newlib (der Compiler-Kern)
Google Test / GMock (Test-Framework, gegen die Toolchain kompiliert)
gcov / lcov (Coverage — muss zur GCC-Version passen)
valgrind (Speicheranalyse — muss die ABI verstehen)
clang-tidy (statische Analyse — braucht die richtigen Header und Bibliotheken des Targets, nicht die des Host-Systems)
clang-format (eine eingefrorene Version verhindert Whitespace-Kriege zwischen Entwicklern)
CMake, Ninja (wenn das CMake der Host-Distribution plötzlich ein Major-Update bekommt, spuckt es unter Umständen in den Build)
QEMU (Target-Emulation für Integrationstests)
Der gemeinsame Nenner: Alles, was das Build-Ergebnis oder die Analyse des Build-Ergebnisses beeinflusst, muss einfrierbar und reproduzierbar sein. clang-tidy klingt zunächst orthogonal — bis man merkt, dass es die Target-Header parsen muss, nicht die des Host-Systems.
Aus der Distribution — unabhängig aktualisierbar:
Doxygen (API-Dokumentation)
srecord (ELF → HEX-Konvertierung)
doctoolchain, asciidoctor (Projektdokumentation)
Diese Werkzeuge beeinflussen weder das Binary noch die Analyse und können unabhängig aktualisiert werden — ohne Firmware-Requalifizierung.
Ein Nebeneffekt der Yocto-basierten Toolchain: Man hat volle Kontrolle über die Compiler-Flags, und zwar in sauberen Schichten.
Auf Bare-Metal fehlen die üblichen OS-Schutzmechanismen
(_stack_chk_fail ohne libc, kein ASLR ohne Loader, kein PIE ohne
MMU). Aber GCC 13+ bietet Hardening-Flags, die _ohne OS
funktionieren:
-fharden-compares
-fharden-conditional-branches
-fharden-control-flow-redundancy
-ftrivial-auto-var-init=zeroDiese Flags landen nicht in der Toolchain selbst (sonst würde newlib
nicht mehr bauen), sondern in einem SDK-Environment-Hook — einer
dünnen Shell-Datei, die beim Aktivieren der Toolchain die
CFLAGS/CXXFLAGS setzt. Drei Schichten:
Distro-Config (Yocto): Flags, die auch newlib braucht (-ffunction-sections, -fdata-sections)
SDK-Hook: Hardening und Warnungen für die Firmware-Entwicklung
Firmware-Projekt (CMakeLists.txt): Projektspezifisches (-std=gnu23, Target-Defines)
In regulierten Branchen liefert man Firmware-Fixes für Produkte,
die vor 10 oder 15 Jahren ausgeliefert wurden. Mit einer
Yocto-basierten Toolchain ist das ein git checkout auf den
Release-Stand und ein bitbake meta-toolchain — fertig.
Yocto liefert dafür zwei Mechanismen, die oft als Implementierungs- detail abgetan werden, aber für das Release-Management essentiell sind:
DL_DIRDas Verzeichnis, in das Yocto alle heruntergeladenen
Quellen ablegt — Tarballs, Git-Snapshots, Patches. Das ist kein
Nebenprodukt, das ist ein Quellenarchiv. Wer DL_DIR archiviert,
kann die Toolchain auch dann noch bauen, wenn die Upstream-Server
längst offline sind.
SSTATE_DIRDer Shared-State-Cache. Yocto speichert hier die Zwischenergebnisse jedes Build-Schritts. Bei einem Release-Fix Jahre später muss nicht alles von Grund auf neu gebaut werden — der Cache beschleunigt den Rebuild auf die tatsächlich geänderten Komponenten.
Beide Verzeichnisse zusammen bilden das Rückgrat für langfristige Nachlieferbarkeit: Quellen gesichert, Build-Ergebnisse nachvollziehbar, Rebuild-Zeiten beherrschbar.
Mit dem Cyber Resilience Act wird die Frage „Was steckt in meiner Toolchain?" regulatorisch relevant. Ein SBOM (Software Bill of Materials) mit voller Provenance ist keine Kür mehr — es wird Pflicht für Produkte mit digitalen Elementen.
Yocto erzeugt SPDX-SBOMs als Nebenprodukt des Builds — für jede
Komponente, die aus den Quellen gebaut wurde. DL_DIR liefert die
Quellenarchivierung, die Rezepte liefern die Abhängigkeitskette,
und INHERIT += "create-spdx" bindet beides zu einem maschinenlesbaren
SBOM zusammen.
Aus Yocto gebaut heißt: Die Provenance stimmt per Konstruktion, nicht per Vertrauen. Das ist ein echtes Pfund, wenn der Auditor vor der Tür steht.
Cross-Compiler für Bare-Metal gibt es an jeder Ecke. Der Mehrwert von Yocto liegt nicht im Cross-Compiler selbst, sondern darin, dass Target-Toolchain, Host-CI-Toolchain und alle Werkzeuge drumherum aus derselben Quelle kommen — reproduzierbar, einfrierbar, CRA-ready.
Die Einstiegshürde ist real: Yocto hat eine steile Lernkurve. Aber wer den Schritt wagt, bekommt eine Toolchain-Infrastruktur, die mit jedem neuen Target und jedem neuen Projekt mitträgt — statt jedes Mal bei null anzufangen.
Eine Jekyll-Site mit AsciiDoc-Unterstützung aufzusetzen bedeutet normalerweise: Ruby installieren, Bundler, eine Handvoll Gems. Mit dem tpo42/adoc-Container und der Dev-Containers-Spezifikation kann man sich das alles sparen.
Der Container ghcr.io/tpo42/adoc bringt Ruby 3.x, Bundler 4.x und die
komplette Asciidoctor-Toolchain mit (asciidoctor, asciidoctor-pdf,
asciidoctor-diagram, …). Jekyll und seine Plugins sind nur ein
bundle install entfernt — kein Grund, das Host-System zuzumüllen.
Ein Standard-Jekyll-Gemfile — der Container liefert Ruby und Bundler, auf dem Host wird nichts weiter benötigt:
source "https://rubygems.org"
gem "jekyll", "~> 4.4"
gem "jekyll-remote-theme"
gem "jekyll-asciidoc"
gem "asciidoctor"
gem "jekyll-sitemap"
gem "jekyll-feed"
gem "jekyll-include-cache"
gem "webrick".devcontainer/devcontainer.json{
"name": "meine-site",
"image": "ghcr.io/tpo42/adoc:latest",
"workspaceFolder": "/workspace",
"workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind",
"postCreateCommand": "bundle config set --local path vendor/bundle && bundle install",
"appPort": [4000, 35729],
"forwardPorts": [4000, 35729],
"portsAttributes": {
"4000": { "label": "Jekyll", "onAutoForward": "notify" },
"35729": { "label": "LiveReload", "onAutoForward": "silent" }
}
}Die wichtigsten Punkte:
imageNutzt direkt ghcr.io/tpo42/adoc:latest (der "einfache Fall" aus
ADR-005). Kein eigenes Dockerfile nötig.
postCreateCommandInstalliert Gems nach vendor/bundle (schreibbar für
den Container-User, von .gitignore ignoriert).
appPortMappt Ports auf Docker-Ebene, damit jekyll serve auch ohne
VS Code vom Host aus erreichbar ist.
forwardPortsDasselbe für VS Codes eingebautes Port-Forwarding.
Mit der devcontainer-CLI:
devcontainer up --workspace-folder .Dann die Site starten:
devcontainer exec --workspace-folder . \
bundle exec jekyll serve --host 0.0.0.0 --livereloadhttp://localhost:4000 öffnen — fertig.
Images wie bretfisher/jekyll-serve funktionieren, bringen aber ihr eigenes
Ruby und Gem-Set mit. Wenn der Content AsciiDoc ist, braucht man die
Asciidoctor-Toolchain und Jekyll — zwei getrennte Container oder ein
aufgeblähtes Custom-Image.
Mit ghcr.io/tpo42/adoc als Basis bekommt man Asciidoctor für die
Dokumentenverarbeitung (flatten, validate, Diagramme extrahieren via adcw)
und Jekyll zum Servieren — aus einem einzigen Image, gesteuert über das
Gemfile des Projekts.
Der adcw-Wrapper braucht keinen Devcontainer. .adoc-Dateien lassen sich
jederzeit validieren:
adcw validate -i _pages/about.adocDas startet einen kurzen docker run --rm — kein langlebiger Container nötig.
appPort vs forwardPortsDie devcontainer-CLI leitet Ports nicht selbst weiter. forwardPorts ist ein
VS-Code-Feature. Für reine CLI-Workflows braucht man appPort.
Der ghcr.io/tpo42/adoc-Container läuft als unprivilegierter User.
bundle install ohne --path versucht in System-Gem-Verzeichnisse zu
schreiben und scheitert. bundle config set --local path vendor/bundle löst
das sauber.
devcontainer up nutzt bestehende Container wieder. Nach Änderungen an
devcontainer.json muss der alte Container erst entfernt werden
(docker rm -f <id>), bevor devcontainer up erneut funktioniert.
Liebe Frau Dr. Vernau,
Sie sind seit Januar 2025 WDR-Intendantin — 7 Monate, um neue Akzente zu setzen. Haben Sie schon bemerkt, was Ihre Redaktionen seit Jahren übersehen?
Lassen Sie mich Ihnen eine Geschichte erzählen, die zeigt, warum dieser Neuanfang nötig ist:
2018 schrieb ich WDR-Redaktionen anlässlich des 20. Deutschen Perl-Workshops in Köln. Internationale Konferenz, 200+ Teilnehmer, direkt vor der WDR-Haustür. Die Antwort der Lokalzeit-Redaktion:
Das Thema erscheint uns zu spezialisiert. Unsere Zuschauer sind nicht herausragend technisch interessiert.
Aktuelle Stunde? Keine Antwort. Wissenschaftsredaktion? Schweigen. Weitere Redaktionen? Totenstille.
Gerade diese Woche: External Secrets Operator für Kubernetes vor dem Aus — nur noch ein Maintainer, völlig überarbeitet. Gernot Starke (arc42, 20 Jahre!) berichtet: “Eine Million Downloads jährlich, hunderte Unternehmen nutzen es täglich — aber Contributions? Nahe Null.”
Das ist die Realität unsichtbarer Communities: Genutzt von allen, unterstützt von wenigen, berichtet von niemandem.
Während Millionen für Fußball-Übertragungen fließen, kostet ein Bericht über deutsche Tech-Communities offenbar zu viel Aufwand für eine Antwort.
Chris Badura aus Köln portiert jährlich ~4 ARM-Architekturen für NetBSD — weltweit genutzt
Gernot Starke feiert mit arc42 das 20-jährige Jubiläum — der Architektur-Standard in DACH
unByte GmbH entwickelt Self-Bootstrapping K8s — Kubernetes-Innovation aus NRW
Yocto Linux mit Contributoren aus Köln, NRW und ganz Deutschland steckt in Milliarden von Geräten
Coocook.org hilft tausenden Ferienlagern bei der Essensplanung
Und das sind nur die, die mir in 30 Sekunden einfallen. Was würde echte Recherche zutage fördern?
Aber Sie zeigen lieber die nächste Influencer-Doku.
Dazu gehört zu zeigen, wer unsere digitale Zukunft gestaltet. Das sind nicht nur die üblichen Verdächtigen aus dem Silicon Valley — das sind auch Menschen aus Köln, Düsseldorf, Essen.
Und diese Menschen gehören in die Prime-Formate, nicht nur in Bildungs-Nischen.
Stellen Sie sich vor: “Austausch in der TH Köln: Coocook-Begründer auf Konferenz” — das wäre in der Lokalzeit eingeschlagen wie eine Bombe. Echter lokaler Bezug, echte Innovation, echte Menschen. Hintergrund-Recherchen gern in Bildungsformaten — aber die Stories müssen raus aus der Nische!
Beauftragen Sie eine Redaktion mit einer Serie über deutsche Tech-Communities. Zeigen Sie die FrOSCon, die Chemnitzer Linux-Tage, den German Perl Workshop. Zeigen Sie die Menschen dahinter.
Nicht als “Nerd-Spektakel”, sondern als das, was es ist: Die Arbeit an unserer gemeinsamen digitalen Zukunft.
Werden Sie die Intendantin, die den Unterschied macht?
Mit freundlichen Grüßen und konkreten Erwartungen,
Jens Rehsack
|
Note
|
Falls Sie Inspiration brauchen — die New York Perl Mongers schauten 2018 nach Köln und sagten: “I had no idea how to celebrate our anniversary. Now I know.” Vielleicht sollte der WDR auch mal nach Köln schauen. |