Haiku assure bien la compatibilité avec les binaires de BeOS. Historiquement c'était très complet, il était même possible d'utiliser les pilotes de périphériques et modules noyau de BeOS.
Cette possibilité pour les modules noyau a été retirée car elle empêchait d'activer des nouvelles fonctionnalités de sécurité (SMAP et SMEP et des permissions plus strictes au niveau du partage de la mémoire et de l'espace utilisateur).
Le noyau peut donc maintenant utiliser du C++ moderne.
Il faut préciser aussi que l'utilisation de gcc2 concerne uniquement la version 32bit x86 de Haiku. Toutes les autres versions (x86 64 bits, RISC-V, et maintenant ARM64 plus les autres en cours de développement) utilisent uniquement un gcc récent.
En revanche, toutes les bibliothèques standard de Haiku sont en C++98 compilable avec gcc2. Le projet maintient une version forkée de gcc2 avec de nombreuses corrections et le report de certaines fonctionnalités plus récentes et indispensables pour pouvoir implémenter la libc standard (par exemple, la possibilité d'utiliser des "wide chars").
Le problème concerne surtout le C++: entre gcc2 et gcc3, le frontend C++ de gcc a beaucoup changé, en particulier, le mangling des symboles a été remplacé pour correspondre à celui défini dans l'ABI officielle du processeur Itanium (il se trouve que c'est le premier processeur à imposer une convention pour le nommage des symboles C++, la même convention est utilisée depuis par gcc sur tous les processeurs).
Pour le C, il y a d'autres possibilités de contournement, nous savons par exemple compiler des versions récentes de ffmpeg avec un compilateur récent et faire en sorte que des applications BeOS compilées avec gcc2 puissent l'utiliser.
En ce qui concerne le C++, une autre possibilité serait de modifier un compilateur récent pour générer des symboles compatibles avec gcc2. C'est un projet qui est mentionné dans les forums de Haiku régulièrement sans que quelqu'un aie vraiment envie de s'y atteler (gros travail en vue, pour peu de bénéfices). On pensait plutôt laisser mourir tranquillement le support du 32 bit dans quelques années, la plupart des applications étant déjà remplacées par d'autres solutions.
Mais, un développeur assisté d'un LLM s'est lancé dans un patch pour clang permettant de générer des bibliothèques avec l'ABI de gcc2. On va voir ce que ça donne, sachant que l'utilisation de LLMs pour contribuer à Haiku est interdite et que les développeurs de clang/llvm ne semblent pas très motivés pour adopter ce code non plus (maintenir une deuxième ABI non standardisée risque de leur compliquer la vie). Cela ne permettrait de toutes façons pas de faire du C++ moderne, car de nombreuses constructions n'ont tout simplement pas de représentation dans l'ABI de gcc2, et la librairie standard C++ n'est pas du tout la même par exemple (celle de gcc2 date d'avant la finalisation du standard C++98 et présente quelques différences).
[^] # Re: GCC 2
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Printemps 2026. Évalué à 10 (+8/-0).
Haiku assure bien la compatibilité avec les binaires de BeOS. Historiquement c'était très complet, il était même possible d'utiliser les pilotes de périphériques et modules noyau de BeOS.
Cette possibilité pour les modules noyau a été retirée car elle empêchait d'activer des nouvelles fonctionnalités de sécurité (SMAP et SMEP et des permissions plus strictes au niveau du partage de la mémoire et de l'espace utilisateur).
Le noyau peut donc maintenant utiliser du C++ moderne.
Il faut préciser aussi que l'utilisation de gcc2 concerne uniquement la version 32bit x86 de Haiku. Toutes les autres versions (x86 64 bits, RISC-V, et maintenant ARM64 plus les autres en cours de développement) utilisent uniquement un gcc récent.
En revanche, toutes les bibliothèques standard de Haiku sont en C++98 compilable avec gcc2. Le projet maintient une version forkée de gcc2 avec de nombreuses corrections et le report de certaines fonctionnalités plus récentes et indispensables pour pouvoir implémenter la libc standard (par exemple, la possibilité d'utiliser des "wide chars").
Le problème concerne surtout le C++: entre gcc2 et gcc3, le frontend C++ de gcc a beaucoup changé, en particulier, le mangling des symboles a été remplacé pour correspondre à celui défini dans l'ABI officielle du processeur Itanium (il se trouve que c'est le premier processeur à imposer une convention pour le nommage des symboles C++, la même convention est utilisée depuis par gcc sur tous les processeurs).
Pour le C, il y a d'autres possibilités de contournement, nous savons par exemple compiler des versions récentes de ffmpeg avec un compilateur récent et faire en sorte que des applications BeOS compilées avec gcc2 puissent l'utiliser.
En ce qui concerne le C++, une autre possibilité serait de modifier un compilateur récent pour générer des symboles compatibles avec gcc2. C'est un projet qui est mentionné dans les forums de Haiku régulièrement sans que quelqu'un aie vraiment envie de s'y atteler (gros travail en vue, pour peu de bénéfices). On pensait plutôt laisser mourir tranquillement le support du 32 bit dans quelques années, la plupart des applications étant déjà remplacées par d'autres solutions.
Mais, un développeur assisté d'un LLM s'est lancé dans un patch pour clang permettant de générer des bibliothèques avec l'ABI de gcc2. On va voir ce que ça donne, sachant que l'utilisation de LLMs pour contribuer à Haiku est interdite et que les développeurs de clang/llvm ne semblent pas très motivés pour adopter ce code non plus (maintenir une deuxième ABI non standardisée risque de leur compliquer la vie). Cela ne permettrait de toutes façons pas de faire du C++ moderne, car de nombreuses constructions n'ont tout simplement pas de représentation dans l'ABI de gcc2, et la librairie standard C++ n'est pas du tout la même par exemple (celle de gcc2 date d'avant la finalisation du standard C++98 et présente quelques différences).