Ce qui se passe
Les binaires statiques sont, selon la formule du projet, une façon merveilleusement ennuyeuse de déployer sur Linux : un fichier, aucune dépendance, rien à casser. Pas de conteneur, pas d'AppImage, pas de bibliothèque manquante chez l'utilisateur.
L'ennui s'arrête net dès que l'application a besoin du GPU. Les pilotes Vulkan et
OpenGL sont fournis par la machine hôte sous forme d'objets partagés, presque
toujours compilés contre la glibc. Un binaire entièrement statique lié à musl
ne peut normalement pas les charger avec dlopen().
C'est exactement le mur que franchit SoLo.
Comment
SoLo fournit une API de style dlfcn — l'interface classique de chargement
dynamique — mais adossée à deux composants maison :
- son propre chargeur ELF, pour x86-64 et aarch64
- un pont vers l'ABI glibc, implémenté au-dessus de musl
Le résultat reste un exécutable statique ordinaire. Un seul fichier, aucune seconde bibliothèque C dans le processus, et pourtant la capacité d'utiliser le pilote graphique déjà installé sur la machine.
La formule qui résume l'intention : l'hôte garde le code spécifique au matériel, vous livrez tout le reste.
La validation
C'est ce qui distingue ce projet d'une démonstration de principe.
Le dépôt inclut une preuve Vulkan de bout en bout : un exécutable entièrement statique charge le pilote Vulkan non modifié de l'hôte, exécute un compute shader et écrit le résultat dans une image PNG. Testé sur les pilotes AMD radv et radeonsi, sur Intel et sur NVIDIA, sur puce Apple M1 sous Asahi Linux, sur Android via Termux, et sous WSL avec le pilote dzn de Mesa au-dessus de Direct3D 12.
Et surtout, à chaque commit, l'intégration continue charge à travers SoLo les bibliothèques partagées des 1 000 paquets Debian les plus installés — plus de 2 100 objets — sur x86-64 et aarch64. C'est une couverture inhabituellement large pour ce type de projet : elle transforme « ça marche sur ma machine » en propriété vérifiée en continu.
Ce que ça change
Le compromis habituel du déploiement Linux opposait la simplicité du binaire statique à l'accès au matériel. Il fallait choisir : soit un fichier autonome sans GPU, soit un conteneur ou un AppImage embarquant tout un environnement.
SoLo desserre ce compromis pour la catégorie précise des applications graphiques ou de calcul GPU distribuées en un seul fichier. Un binaire à télécharger, rendre exécutable, et lancer — qui utilise malgré tout le pilote de la machine.
À retenir
Un chargeur ELF et un pont d'ABI permettent à un binaire musl statique de
dlopen() des objets glibc. La preuve Vulkan fonctionne sur cinq familles de
matériel, et la CI vérifie le chargement de plus de 2 100 bibliothèques à chaque
commit.
Source : github.com/pg83/solo