Comment les applications se résolvent-elles à des versions différentes des bibliothèques partagées au moment de l'exécution ?

Question

Je suis un noob sur la façon dont les bibliothèques partagées fonctionnent sur linux. J'essaie de comprendre comment les applications résolvent les différentes révisions de la même bibliothèque partagée au moment de l'exécution sur linux.

D'après ce que je comprends, une bibliothèque partagée a trois "noms", par exemple,

1. libmy.so.1.2 (nom réel, c'est-à-dire le fichier obj actuel)
2. libmy.so.1 (SONAME, qui est incorporé dans le fichier obj actuel)
3. libmy.so (nom de l'éditeur de liens, fourni à l'éditeur de liens au moment de la liaison et intégré à l'exécutable)

Lorsque vous installez la bibliothèque via LDCONFIG, celle-ci crée les liens symboliques suivants

• (2) => (1)
• (3) => (2)

Maintenant, disons que je compile une autre version de la même bibliothèque avec le nom réel suivant, libmy.so.2.0. Le SONAME par principe serait libmy.so.2.0.

Au moment de la liaison de l'application, quel est le nom de l'éditeur de liens que je dois fournir avec l'option "-l". En suivant les directives que j'ai lues ( http://www.dwheeler.com/program-library/Program-Library-HOWTO/x36.htm l), ne devrait-il pas s'agir de libmy.so et, dans ce cas, comment distinguer les deux versions du fichier obj ?

Answer 1

Le versionnement des objets partagés fonctionne comme suit :

Lorsque vous créez un objet partagé, vous lui donnez à la fois un nom réel et un nom d'utilisateur. soname . Ils sont utilisés pour installer l'objet partagé (qui crée à la fois l'objet et un lien vers celui-ci).

Vous pouvez donc vous retrouver dans cette situation :

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so.1 -> xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.1

avec xyz.so.1.5 possédant le SONAME de xyz.so.1 .

Lorsque l'éditeur de liens se connecte à xyz.so il suit les liens jusqu'à xyz.so.1.5 et utilise son SONAME de xyz.so.1 à stocker dans l'exécutable. Ensuite, lorsque vous exécuter l'exécutable, il essaie de charger xyz.so.1 qui pointera vers un xyz.so.1.N (pas nécessairement la version 1.5).

Vous pourriez donc installer xyz.so.1.6 et mettre à jour le xyz.so.1 pour pointer vers lui à la place et les exécutables déjà liés l'utiliseront à la place.

Un avantage de cette méthode multicouche est que vous pouvez avoir plusieurs bibliothèques potentiellement incompatibles du même nom ( xyz.so.1.* , xyz.so.2.* ) mais, à l'intérieur de chaque version majeure, vous pouvez librement les mettre à niveau puisqu'ils sont censés être compatibles .

Lorsque vous liez de nouveaux exécutables :

• Ceux qui établissent des liens avec xyz.so obtiendra la dernière version mineure de la dernière version majeure.
• Autres liens avec xyz.so.1 permet d'obtenir la dernière version mineure d'une version majeure spécifique.
• D'autres encore établissent des liens avec xyz.so.1.2 obtiendra une version mineure spécifique d'une version majeure spécifique.

Gardez ce dernier paragraphe à l'esprit lorsque nous examinerons votre commentaire :

Maintenant, disons que je compile une autre version de la même bibliothèque avec le nom réel suivant, libmy.so.2.0 . Le SONAME par directives serait libmy.so.2.0 .

Non, je ne le crois pas. Le site soname seraient plus susceptibles d'être libmy.so.2 afin que vous puissiez effectuer des mises à jour mineures du 2.x et obtenir les derniers comportements.

Answer 2

Au moment de la liaison de l'application, si vous spécifiez -lmy l'éditeur de liens cherchera un fichier nommé libmy.so . Il trouvera ce fichier et liera votre exécutable avec lui. Si ce fichier est un lien symbolique, alors votre application sera liée avec la cible du lien symbolique.

Le temps de liaison de l'application est le site pour préciser la version de la bibliothèque dynamique que vous souhaitez utiliser avec votre application.

Answer 3

1. Les libéraux ont des versions différentes dans le nom.
2. Les paquets avec le nom "lib" ont seulement des libs et ont des versions différentes dans le nom.
3. Le système ne compilera qu'avec la dernière bibliothèque, sauf si vous en définissez une autre.
4. L'application n'utilise que les bibliothèques dont elle a besoin. Vérifiez ldd , readelf.
5. Les applications contiennent un lien entre les fichiers .so et .pc, vérifiez le système rpm pour savoir quoi. https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging#Devel_Packages