Si vous avez quelques années d’expérience dans l’écosystème Linux et que vous souhaitez partager cette expérience avec la communauté, consultez nos Directives de contribution.

Dans ce tutoriel, nous allons expliquer comment nous pouvons avoir plusieurs bibliothèques glibc sur une machine Linux. Nous commencerons par discuter de la possibilité d’avoir plusieurs bibliothèques et des problèmes qui pourraient en découler. Ensuite, nous examinerons plusieurs façons d’utiliser plusieurs versions de glibc sur la même machine.

Différentes versions d’une Bibliothèque Partagée sous Linux

Il est possible d’avoir des installations de plusieurs versions des mêmes bibliothèques partagées sur une machine Linux. L’éditeur de liens, lors de la compilation du programme, recherche un lien logiciel qui renvoie à une version spécifique d’une bibliothèque. Par exemple, dans le cas de la glibc, le libglib-2.0.so le lien sous le répertoire /usr/lib pointera vers une version particulière de la glibc.

Sous Linux, la convention pour nommer les bibliothèques partagées est lib .so…. Les variables de la convention ont des significations différentes:

name est le nom de fichier de l'objet partagé (bibliothèque partagée)
major est la version API de la bibliothèque — les mises à niveau majeures peuvent introduire une incompatibilité rétroactive
minor est la version mineure de la version de l'API, qui indique de nouvelles fonctionnalités
patch signifie correctifs pour les bugs

Ainsi, d’une certaine manière, nous pouvons avoir plusieurs versions de glibc sur notre machine et avoir un libglib-2.0.so lien vers une version spécifique. L’éditeur de liens recherchera le champ soname dans l’objet partagé et l’intégrera dans le binaire résultant. Le champ soname spécifie le nom de fichier de notre bibliothèque partagée cible. Par conséquent, pendant l’exécution, l’éditeur de liens dynamique recherchera la bibliothèque partagée spécifiée dans le champ soname.

Pour cette raison, nous pourrons utiliser différentes versions de la glibc dans notre programme. Une mise en garde de cette approche est que nous ne pouvons pas utiliser plusieurs versions de la même bibliothèque dans notre programme en même temps. Néanmoins, nous pouvons utiliser la liaison statique si différentes versions d’une même bibliothèque sont une nécessité absolue.

Spécification d’une glibc différente de g++

la glibc n’est pas un fichier autonome que nous pouvons lier dans nos programmes. Cela dépend de nombreux autres modules. L’un d’eux est ld-linux. L’outil ld ou éditeur de liaison est un utilitaire d’assistance qui combine plusieurs fichiers objets et d’autres ressources en un seul fichier de sortie. Par conséquent, nous devons spécifier la version correcte de ld-linux en g++ avec glibc.

Maintenant, si nous avons une version différente de glibc et la version appropriée de ld-linux, nous pouvons compiler notre code source avec notre bibliothèque glibc ciblée:

$g++ – o – Wl,rrpath=/chemin/glibc-Wl,dynamicdynamic-linker=/chemin/glibc/ld-linux.so.2

Décomposons-le:

Nous construisons notre fichier avec g++ et spécifions le nom de sortie avec l'option -o
- Wl activera de longs avertissements pour lier la bibliothèque glibc
- l'option rpath indique au chargeur d'exécution de rechercher les bibliothèques requises dans le répertoire /path/glibc
l'option -dynamic-linker fournit le chemin correct vers ld-linux.so.2 dans le binaire résultant

Alternativement, nous pourrions également exporter le chemin LD_LIBRARY_PATH pour inclure le chemin vers notre répertoire glibc avant d’exécuter notre application. Cependant, tout nouveau processus enfant lancé par le programme doit également utiliser la glib plus récente comme spécifié dans cette variable. Sinon, s’ils ne sont pas compilés avec la nouvelle glibc ou si l’environnement de processus enfant n’hérite pas de l’environnement parent. Ainsi, nous devrions nous en tenir à l’option –rpath et éviter d’utiliser la variable d’environnement.

Utilisation de patchelf

Cette approche fonctionne bien lorsque nous avons le code source de notre programme. D’un autre côté, il devient un peu compliqué de relier à nouveau les binaires car nous devons faire beaucoup de travail manuel, comme créer un environnement chroot. Pour cette raison, nous pouvons utiliser patchelf pour nous faire gagner du temps et des maux de tête.

patchelf est un utilitaire que nous pouvons utiliser pour modifier facilement le rpath et l’éditeur de liens dynamique d’un exécutable ELF. ELF signifie Format exécutable et Liable. C’est le format de fichier standard pour les binaires et les bibliothèques sous Linux. Ceux-ci incluent . donc,.o, et les fichiers exécutables qui n’ont pas d’extensions spécifiques.

Installation de patchelf

Certaines distributions sont livrées avec un patchelf préinstallé. Cependant, s’il n’est pas installé, nous pouvons l’installer à partir du référentiel officiel de notre distribution à l’aide d’un gestionnaire de paquets.

Sur les dérivés d’Ubuntu et Debian:

apt installer patchelf

Pour RHEL et Fedora:

miam installer patchelf

Sur la base de l’arche:

pacman-L patchelf

Une fois patchelf installé, vérifions-le:

patchpatchelfversionversion
patchs 0.14.3

Utilisation

L’utilisation de patchelf est assez simple. La syntaxe de base de la commande patchelf est:

patchpatchelf [OPÉRATION] [OPTIONS]

Nous allons passer en revue les différentes opérations CRUD pour rpath.

Tout d’abord, nous ajouterons un rpath à notre exécutable binaire pour notre glibc préférée:

patchpatchelfaddadd-rpath/path/glibc – ancien my_prog

De même, nous pouvons mettre à jour le rpath avec l’option –set-rpath. Cela pourrait casser le programme, alors utilisez-le avec prudence:

patchpatchelfsetset-rpath »/path/glibc-older:/path/libsdl:/path/libgl » my_prog

Pour supprimer un rpath existant:

patchpatchelfremoveremove-rpath/path/glibc – ancien my_prog

Nous pouvons également mettre à jour l’éditeur de liens dynamique avec -set-interpreter:

patchpatchelf — ensemble-interpréteur /chemin/glibc- plus ancien/ld-linux/ld-linux.so.2

Maintenant, disons que nous voulons utiliser la dernière bibliothèque glibc existante située dans le répertoire /usr/lib. Nous pouvons simplement mettre à jour le soname de notre fichier ELF:

patchpatchelf libset-soname libglib-2.0.so.0.7000.2

Conclusion

Dans cet article, nous avons vu comment nous pouvions avoir plusieurs versions des mêmes bibliothèques sur un seul hôte. Nous avons parcouru plusieurs façons d’utiliser plusieurs glibc sur notre machine avec g++ et patchelf.