Les numéros de Version de l'objet partagé des fichiers

Je suis en train de construire un fichier objet partagé à partir d'un groupe de fichiers source C++ avec GCC. Tous les exemples de tutoriels sur la construction de .so fichiers afficher le fichier créé avec un numéro de version après la .so suffixe. Par exemple:

gcc -shared -Wl,-soname,libmean.so.1 -o libmean.so.1.0.1  calc_mean.o

Ce serait de produire la .so fichier libmean..1.0.1

En outre, si je navigue dans le /usr/lib répertoire sur ma machine locale, je vois que beaucoup de la .so fichiers ont des numéros de version à la fin.

Cependant, quand je compile un fichier objet partagé et le placer dans /usr/lib, le linker ne trouve pas ça si j'ai mis un numéro de version à la fin. Si je supprime le numéro de version, il fonctionne très bien. J'ai vraiment ne se soucient pas de mettre un numéro de version ou pas, je ne comprends juste pas pourquoi cela semble être d'une convention commune, et pourtant, cela provoque la bibliothèque partagée de ne pas travailler avec l'éditeur de liens. Donc, ce qui se passe ici? Pourquoi est-il une convention pour placer le numéro de version à la fin d'une .so nom de fichier?

OriginalL'auteur Channel72 | 2011-04-22

  1. 17

    Le numéro de version est ajouté de sorte que vous pouvez avoir plusieurs incompatible bibliothèque versions coexistent dans le système. Vous devez incrémenter le numéro de version majeure (le nombre soname) chaque fois que vous changez l'API d'une façon incompatible (en supposant que la version précédente est installé et utilisé dans le système, bien sûr).

    Les 2e et 3e chiffres dans le nom de fichier permet de multiples révisions mineures de la bibliothèque dans le système, commutable à l'échelle du système avec un simple lien symbolique de mise à jour.

    Au moment de la liaison, vous pouvez donner le .so nom de fichier comme un éditeur de liens argument, au lieu de -l option. ldd est assez intelligent pour extraire le soname, le binaire lié de cette manière qu'il utilise pour trouver la bibliothèque.

    Par exemple, nous allons compiler la bibliothèque et binaire de test à l'aide de:

    czajnik@czajnik:~/z$ gcc -shared -Wl,-soname,libtest.so.2 -o libtest.so.2.3.4  a.c 
czajnik@czajnik:~/z$ gcc -o test b.c -L. ./libtest.so.2.3.4

    Vous pouvez utiliser la commande ldd à vérifier, que le binaire regarde maintenant pour libtest.so.2:

    czajnik@czajnik:~/z$ LD_LIBRARY_PATH=. ldd ./test
    linux-gate.so.1 =>  (0x002c1000)
    libtest.so.2 => not found
    libc.so.6 => /lib/libc.so.6 (0x00446000)
    /lib/ld-linux.so.2 (0x00a28000)

    Il est évident qu'elle ne peut pas le trouver, mais c'est ce que le lien est:

    czajnik@czajnik:~/z$ ln -s libtest.so.2.3.4 libtest.so.2
czajnik@czajnik:~/z$ LD_LIBRARY_PATH=. ldd ./test
    linux-gate.so.1 =>  (0x00d75000)
    libtest.so.2 => ./libtest.so.2 (0x00e31000)
    libc.so.6 => /lib/libc.so.6 (0x00a5e000)
    /lib/ld-linux.so.2 (0x00378000)

    Mise à jour: Tout ce qui précède est vrai, mais je n'étais pas moi-même conscient de la signification de la composante 3 du numéro de version. Jusqu'à récemment, je pense que c'est simplement un numéro de patch (ou autre chose). Faux! Pour libtool il a une signification particulière.

    La 3ème composante s'est avéré être âge champ, qui dit combien de versions principales sont rétro-compatibles avec une.

    Lecture recommandée:

    Je n'ai pas tout à fait l'âge de la composante de votre réponse. libtool doc a dit "[âge] est La différence entre la plus récente et la plus ancienne des interfaces de cette bibliothèque implémente. En d'autres termes, la bibliothèque met en œuvre tous les numéros d'interface dans la gamme du numéro actuel de l'âge actuel." Je pense que c'est une meilleure explication.
    D'abord l'un des 2 liens dans "lectures recommandées" points de Martin Sustrik de l'article du blog, qui explique assez bien.
    Hmm, peut-être que la réponse est en effet la peine de mise à jour, je vais faire dans un instant.

    OriginalL'auteur Code Painters