1. Pourquoi compiler une version récente de libdrm ? Expérience pratique

Si vous développez des applications graphiques, en particulier celles qui interagissent directement avec le matériel d'affichage comme les interfaces graphiques embarquées, lecteurs vidéo ou moteurs de jeu, vous ne pouvez probablement pas contourner le sous-système DRM (Direct Rendering Manager) du noyau Linux. En termes simples, il s'agit du "gestionnaire principal" qui supervise les cartes graphiques et les moniteurs sous Linux. La bibliothèque libdrm représente ensuite le "kit d'outils standard" que ce gestionnaire met à disposition des programmes en espace utilisateur.

Ma première rencontre avec libdrm a eu lieu dans le cadre d'un projet embarqué nécessitant la mise en œuvre d'un lecteur vidéo à faible latence sur une carte ARM. À cette époque, j'utilisais encore une version ancienne de la bibliothèque, ce qui a provoqué une erreur de compilation lors de l'essai d'utilisation du mode atomic pour configurer les paramètres d'affichage. Après quelques recherches, j'ai découvert que les opérations atomic constituaient une méthode plus puissante et plus sûre de configuration du matériel, introduite plus tard dans DRM, mais que l'ancienne version de libdrm ne fournissait tout simplement pas l'interface d'encapsulation correspondante. C'est comme si vous essayiez de contrôler une nouvelle lampe intelligente avec un protocole récent en utilisant une télécommande datant de dix ans qui ne supporte pas cette fonctionnalité - la seule solution est de changer de télécommande. Dans mon cas, cette "nouvelle télécommande" était libdrm 2.4.109.

Par conséquent, compiler une version récente de libdrm n'est pas une option mais une nécessité, surtout lorsque vous avez besoin de fonctionnalités graphiques modernes comme les soumissions atomic ou la synchronisation explicite (explicit sync). Les paquets précompilés disponibles dans les dépôts officiels sont souvent obsolètes ou ne contiennent pas la configuration spécifique dont vous avez besoin (comme une bibliothèque statique). Compiler vous-même non seulement garantit que vous utilisez la dernière version, mais vous permet également de personnaliser en fonction de votre plateforme cible (par exemple ARM) et de vos besoins (statique ou dynamique), offrant ainsi beaucoup plus de flexibilité. Pour cet article, je vais détailler le processus complet de compilation de libdrm 2.4.109 et de génération d'une bibliothèque statique sur Ubuntu 16.04, un système "classique" mais quelque peu ancien, en partageant les étapes et les difficultés rencontrées.

2. Configuration de l'environnement de compilation : Résolution des problèmes de dépendances

Ubuntu 16.04 est une version LTS très stable, mais ses dépôts logiciels sont quelque peu "âgés", et de nombreux outils disponibles via apt-get install ont des versions insuffisantes pour les logiciels récents. Pour compiler libdrm 2.4.109, nous avons besoin de deux outils essentiels : meson (système de build) et ninja (outil de construction). Les nouvelles versions de libdrm ont abandonné l'approche traditionnelle ./configure && make au profit du duo plus moderne et plus rapide meson+ninja.

Commençons par installer les outils de base fournis par le gestionnaire de paquets du système. Ouvrez un terminal et exécutez :

sudo apt-get update
sudo apt-get install python3 python3-pip ninja-build re2c git build-essential pkg-config

Quelques points méritent d'être notés. python3 et pip3 sont indispensables car meson est un outil écrit en Python. ninja-build est le nom du paquet ninja dans les dépôts Ubuntu. re2c est un compilateur requis lors de la compilation des nouvelles versions de ninja, il est donc préférable de l'installer à l'avance. build-essential fournit la chaîne d'outils de base comme gcc et make, tandis que pkg-config aide à la recherche de fichiers de bibliothèque - tous sont des contributeurs essentiels en coulisses du processus de compilation.

Une fois ces éléments installés, essayons d'installer meson avec pip :

pip3 install --user meson

Cette commande installlera meson pour l'utilisateur actuel. Après l'installation, ajoutez le répertoire bin local de l'utilisateur à la variable d'environnement PATH pour que le terminal puisse trouver la commande meson. Vous pouvez l'ajouter à la fin du fichier ~/.bashrc :

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Maintenant, en exécutant meson --version, vous devriez voir un numéro de version, comme 0.56.0 ou supérieur. L'étape avec meson se déroule généralement sans problème. Les vrais "pièges" apparaissent souvent avec ninja. Exécutez ninja --version et vous verrez probablement sur Ubuntu 16.04 une version comme 1.5.x ou 1.6.x. Cependant, le système de build de libdrm 2.4.109 exige que ninja soit au moins en version 1.8.2. Cette incompatibilité de version provoquera des erreurs lors de la compilation.

2.1 Compilation manuelle d'une version récente de Ninja

La version disponible dans les dépôts système étant trop ancienne, nous devons compiler manuellement ninja depuis les sources. Ne vous inquiétez pas, ce processus est assez simple. ninja est écrit en C++ et se compile très rapidement.

D'abord, récupérons les sources de ninja les plus récentes (ou une branche d'une version stable) :

git clone https://github.com/ninja-build/ninja.git
cd ninja

Une fois dans le répertoire des sources, nous pouvons vérifier quelles versions sont disponibles