Cross-Compilation mit Lyx

lyxc ist ein self-contained Cross-Compiler: kein externer Linker, keine separate Toolchain-Konfiguration. Eine einzige Binary erzeugt nativen Code für alle unterstützten Zielplattformen.

→ Guides · Compiler-Parameter

Standard: Kein –target → Host-Plattform (in der Regel linux/x86_64).

lyxc main.lyx --target=arm64 -o firmware.elf

# Mit Energy-Optimierung für Batteriebetrieb:
lyxc main.lyx --target=arm64 --target-energy=1 -o sensor.elf

# Safety-Build (DO-178C):
lyxc flight.lyx --target=arm64 --lint --static-analysis -o flight.elf

Die erzeugte ELF verwendet /lib/ld-linux-aarch64.so.1 als Dynamic Linker — das muss auf dem Zielsystem vorhanden sein. Für Systeme ohne Standard-Loader:

lyxc main.lyx --target=win64 -o app.exe
lyxc main.lyx --target=windows-arm64 -o app_arm64.exe

Erzeugt eine vollständige PE32+-Datei. Keine Wine- oder MSVC-Installation nötig.

Seit lyxc 1.1.3E sind aus einer solchen Binary auch Win32-Funktionen erreichbar: extern fn … link „kernel32.dll“ landet in der Import-Tabelle, mehrere DLLs nebeneinander sind zulässig, und Umgebungsvariablen (EnvLookupRaw, std.datetime, std.os) lesen den Windows-Umgebungsblock (#1671, #1674, #1676, #1677). Auch die frühere Größengrenze ist weg: eine Relokationstabelle über 0x1000 machte die Datei vorher unstartbar (#1672).

# Generisches RISC-V RV64GC:
lyxc main.lyx --target=riscv -o controller.elf

# Linux-spezifisch (mit Linux ABI-Optimierungen):
lyxc main.lyx --target=linux-riscv64 -o app.elf

Einschränkung: Kein Dynamic Linking für RISC-V — immer statisch linken (–static) oder -l-Flags vermeiden.

Für STM32, nRF52, RP2040 und kompatible Cortex-M4/M33-Systeme:

# Cortex-M4 / Cortex-M33:
lyxc main.lyx --target=arm-cm4 --no-libc-init -o firmware.elf

# Generisch Cortex-M (M0/M3):
lyxc main.lyx --target=arm_cm --no-libc-init -o firmware.elf

Wichtig: Kein Hardware-FPU-Support — Fließkomma läuft als Software-Emulation. Für DO-178C mit FPU: die betroffenen Funktionen mit @flight_crit annotieren — ein –no-fp-fold gibt es nicht.

Das ELF32-Format enthält e_flags = EABI5 | Thumb-interwork — direkt flashbar mit objcopy oder openocd.

lyxc main.lyx --target=esp32 --no-libc-init -o app.elf
lyxc main.lyx --target=esp32s3 --no-libc-init -o app_s3.elf

Status: läuft, aber ohne Hardware-Nachweis. Die Defektkette, die hier früher als „Segfault bei komplexen Programmen„ stand, ist mit lyxc 1.1.9N behoben (#1782); Division und Modulo, die still 0 lieferten, mit 1.1.10G (#1789). Was bleibt:

• Kein f64-Rechnen — Addition und Vergleich brechen beim Übersetzen ab (nachgemessen mit 1.1.11B)
• Kein Dynamic Linking
• Die Multiplikation ist nicht ausführbar geprüft — in keinem verfügbaren QEMU-Kern gibt es Mul32 (#1790). Das gilt sinngemäß für das ganze Ziel: geprüft ist, was der Compiler erzeugt, nicht was der Chip daraus macht.

Android-Bibliotheken werden als .so erzeugt:

lyxc mylib.lyx --target=android --output-type=shared-lib -o libmylib.so

# Android API-Level explizit setzen (Default: 26 = Android 8.0, Minimum: 21):
lyxc mylib.lyx --target=android --android-api=29 --output-type=shared-lib -o libmylib.so

# Android x86_64 (Emulator):
lyxc mylib.lyx --target=android-x86_64 --output-type=shared-lib -o libmylib_x86.so

JNI-Funktionen werden mit @jni annotiert — der Compiler mangelt den Namen automatisch in das Java-Format Java_<class>_<method>:

import std.io;

@jni(class="com/example/MyApp", method="hello")
pub fn hello(): void {
  PrintLn("Hello from Lyx via JNI!");
}

@jni(class="com/example/MyApp", method="add")
pub fn add(a: int64, b: int64): int64 {
  return a + b;
}

Das erzeugte .so enthält ein .note.android.ident-Section mit dem API-Level — erforderlich für den Android-Loader.

Für Microcontroller und Custom-Bootloader ohne OS-Unterstützung:

lyxc main.lyx --target=arm-cm4 --no-libc-init --static -o bare.elf

Was –no-libc-init bewirkt:

• Kein __libc_start_main-Aufruf
• Kein DT_NEEDED libc.so.6 im ELF
• 12-Byte BL main + exit-Stub statt 56-Byte Standard-_start
• main() wird direkt als Einstiegspunkt verwendet

lyxc benötigt keinen externen Linker (kein ld, lld, arm-none-eabi-ld). Der Compiler schreibt das fertige Binary (ELF64/ELF32/PE32+/Mach-O) direkt — Parsing, Codegen und Linking in einem Schritt.

Externe C-Bibliotheken werden trotzdem unterstützt:

# C-Bibliothek linken (lyxc löst Symbole selbst auf):
lyxc main.lyx -lm -lpthread -o app

# Eigene Shared Library einbinden:
lyxc main.lyx -L/opt/mylibs -lmylib -o app

Die frühere Zeile „ESP32: Segfault bei komplexen Programmen“ ist entfallen. Die Ursache war eine Defektkette im xtensa-Backend — Argumente, Param-Spill, Vorwärtsaufrufe, Feld-Offsets, Einstiegspunkt —, behoben mit lyxc 1.1.9N (#1782, #1765). Dazu kamen Division und Modulo, die vorher still 0 lieferten (#1789, 1.1.10G), sowie Zeichenkettenliterale und PC-relative Adressierung (#1786). Dieselbe Kette auf riscv war #1740 (1.1.9A) — dort waren es acht Defekte auf einmal, weil das Backend bis dahin nie ausgeführt geprüft worden war.

Gemessen mit lyxc 1.1.11B: je ein Minimalprogramm pro Zeile, für jedes Ziel übersetzt. ✓ heißt „der Compiler erzeugt ein Binary„, nicht „auf dem Gerät nachgerechnet“ — für arm-cm4 und esp32 fehlt uns dafür die Hardware.

Gegenüber dem Stand 1.0.21A hat sich das Bild grundlegend gedreht:

• arm64 und riscv rechnen f64 vollständig. Der frühere Ausfall beim Vergleich (arm64, Opcode 42) und bei der Addition (riscv, Opcode 20) ist weg.
• con-Konstanten waren auf allen IR-Zielen 0 — die Vorab-Erfassung der Modul-Globalen kannte nur NK_VAR_DECL, nicht NK_CON_DECL (#1751, 1.1.8A). Ein reiner Übersetzungstest wäre grün gewesen; der Fehler saß im erzeugten Code. Nachgezogen: f64-Konstanten (#1801), ~0 im Anfangswert (#1799) und negative f64 (#1803).
• import std.io trägt jetzt auf allen IR-Zielen. Die frühere Aussage „scheitert für alle IR-Ziele, dort fehlen 194 Builtins„ (#1388) gilt nicht mehr.
• Virtueller und Interface-Dispatch laufen auf dem IR-Pfad über einen type-id-Switch statt über eine VMT (#1773, 1.1.9G) — kein eigenes Layout, keine Interface-Tabellen.

Letzte Aktualisierung: 2026-08-27 — Einschränkungstabelle und Ziel-Matrix gegen lyxc 1.1.11B neu erhoben (je ein Minimalprogramm pro Zeile und Ziel übersetzt): #1740, #1751, #1765, #1782, #1786, #1789, #1799, #1801, #1803 behoben, #1388 hinfällig.

Vorherige Aktualisierung: 2026-08-19 — Windows-Abschnitt um DLL-Aufrufe, Umgebungsvariablen und die Relokationsgrenze ergänzt (#1671, #1672, #1674, #1676, #1677), unter Wine mit lyxc 1.1.3I nachgemessen.

Vorherige Aktualisierung: 2026-08-15 — Gleitkomma-Matrix gegen 1.0.20A gemessen (#1339)