Note de travail — cible Rust *-linux-air (chaîne d’outils)

Statut : note exploratoire, NON engageante (docs/notes/, cf. INDEX). Graduera en ADR le jour où l’on décide de produire la chaîne. Énoncée par le BDFL le 2026-06-27.

Idée

Produire une cible Rust *-linux-air : un target dont le std et l’édition de liens lient par défaut la libc Air → tout exécutable construit est « natif » (zéro glibc/musl) par construction, sans dépendre de l’analyse DT_NEEDED à l’exec. La signature reste l’ancre de confiance ; la cible garantit la conformité à la source.

Précédents : Redox (*-unknown-redox + relibc). Modèle technique : eyra/c-scape (std → libc Rust via origin/rustix, aucune libc C).

1. QUAND le produire

• Prérequis fonctionnel : la libc Air couvre la surface std (threads/pthread, fichiers, process, env, malloc). État actuel : T1+T2 (identifiants + AirLog) → loin.
• Poule/œuf : la cible compile un userland natif ; un userland natif justifie la cible.
• → Quand : libc Air ≈ complète côté std et userland à compiler. Pas avant.

2. QUOI (la chaîne)

• target spec *-linux-air (triple + JSON ou upstream) : linker, libs par défaut, std backend ;
• std bâti sur la libc Air (gros morceau — modèle eyra) ;
• CRT/startup (init runtime Air) + config linker liant libair-c par défaut (jamais glibc/musl) ;
• build-std ou std prébuilt pour la cible ;
• pipeline build + signature (provenance : produit les binaires signés natifs).

3. PRÉREQUIS OS pour CONSTRUIRE (2 phases)

• Bootstrap (cross-build) : host Ubuntu + rustc stable + linker (lld/ld). Prérequis modestes ; la libc Air (Rust + syscalls bruts) se compile sur tout Linux.
• Cible runtime : Air = noyau Linux 6.x (couche 0 : io_uring/Landlock/clone3). C’est l’ABI visée, pas le host de build.
• Self-host (à terme) : la chaîne tourne sur Air ; prérequis = libc Air couvre rustc/cargo.

→ Construire ne demande d’abord qu’un Linux de dev standard ; les vraies exigences sont le runtime cible (6.x) puis le self-host.

4. Toolchain C *-linux-air (clang) — AUSSI nécessaire

On ne peut pas exclure le C (cohabitation). Or rustc ne compile PAS le C ; cargo non plus (il délègue via le crate cc à un compilateur C externe clang/gcc). → il FAUT un compilateur C pour *-linux-air. Choix clang (cross-target par --target+sysroot, là où gcc exige un cross-build par cible ; + backend LLVM partagé avec rustc, LTO Rust↔C).

Le point clé : UN seul sysroot, DEUX front-ends. rustc-*-linux-air et clang-*-linux-air consomment le même sysroot Air = headers (libc Air + air_base.h + headers C standard fournis par la libc Air) + libair-c + CRT/linker (lie libc Air par défaut, jamais glibc/musl). Le gros du travail = libc + sysroot (commun) ; la part clang est bon marché (pointer clang sur le sysroot). Posture : clang amont NON forké (dép d’outillage ADR-024, comme cbindgen/Doxygen/capnp) — on possède le sysroot, pas le compilateur. (Air bannit le C dans ses propres crates — check-c-surface ; clang sert au userland C tiers porté.)

5. C++ *-linux-air — ajout SÉPARABLE (pas un nouveau compilateur)

clang compile déjà C et C++ (clang++ = clang en mode C++) → aucun compilateur C++ à construire. Le C++ exige seulement, au-dessus de la libc C, des runtimes : libc++ (std C++), libc++abi (ABI : exceptions/RTTI/new/delete), libunwind (déroulement de pile pour les exceptions) — projets LLVM amont, à porter sur le sysroot Air (new/ delete → allocateur Air). Donc C-clang n’entraîne PAS C++ : le support C++ est un ajout optionnel/différable (poser les 3 runtimes dans le sysroot quand on veut le userland C++). Choix LLVM-cohérent (libc++ plutôt que libstdc++ GCC). Nuance : exceptions C++ = unwinding (libunwind) vs Air Rust panic=abort no-unwind → pas de conflit (le programme C++ porté, probablement confiné, embarque SON runtime d’exceptions ; n’affecte pas le code Rust d’Air).

Lien : vision libc [[air-libc-rust-vision]] (exécution par provenance, modèle eyra).