Plusieurs bibliothèques glibc sur un seul hôte

Question

Plusieurs bibliothèques de la glibc sur un hôte unique

Mon linux (SLES-8) serveur actuellement a la glibc 2.2.5-235, mais j'ai un programme qui ne fonctionne pas sur cette version et nécessite de la glibc 2.3.3.

Est-il possible d'avoir plusieurs glibcs installé sur le même hôte?

C'est l'erreur que j'obtiens lorsque j'exécute mon programme sur l'ancienne bibliothèque glibc:

./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./myapp)
./myapp: /lib/i686/libpthread.so.0: version `GLIBC_2.3.2' not found (required by ./myapp)
./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./libxerces-c.so.27)
./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by ./libstdc++.so.6)
./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./libstdc++.so.6)

J'ai donc créé un nouveau répertoire appelé newglibc et copié les fichiers suivants:

libpthread.so.0
libm.so.6
libc.so.6
ld-2.3.3.so
ld-linux.so.2 -> ld-2.3.3.so

et

export LD_LIBRARY_PATH=newglibc:$LD_LIBRARY_PATH

Mais j'obtiens une erreur:

./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libpthread.so.0)
./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by libstdc++.so.6)
./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libm.so.6)
./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by ./newglibc/libc.so.6)
./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libc.so.6)

Il semble donc qu'ils sont encore en les reliant à /lib et de ne pas reprendre de là où je les mettre?

Merci

Answer 1

Il est très possible d'avoir plusieurs versions de la glibc sur le même système (nous le faisons chaque jour).

Toutefois, vous devez savoir que la glibc se compose de nombreuses pièces (200+ bibliothèques partagées) qui tous doivent correspondre. L'une des pièces est ld-linux..2, et il doit correspondre à la libc..6, ou vous pourrez voir les erreurs que vous voyez.

Le chemin d'accès absolu de ld-linux..2 est codée en dur dans le fichier exécutable au moment de la liaison, et ne peut pas être facilement modifiés après le lien est fait.

Pour créer un fichier exécutable qui va travailler avec la nouvelle glibc, faites ceci:

g++ main.o -o myapp ... \
   -Wl,--rpath=/path/to/newglibc \
   -Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2

L' -rpath linker option, l'exécution du chargeur de recherche pour les bibliothèques en /path/to/newglibc (de sorte que vous n'avez pas de fixer LD_LIBRARY_PATH avant de l'exécuter), et l' -dynamic-linker option "cuire" chemin d'accès de corriger ld-linux.so.2 dans l'application.

Si vous ne pouvez pas relier l' myapp application (par exemple, parce que c'est un tiers binaire), tout n'est pas perdu, mais il est plus difficile. Une solution est de mettre un bon chroot environnement. Une autre possibilité est d'utiliser rtldi et un éditeur binaire.

Answer 2

Utilisez LD_PRELOAD: placez votre bibliothèque quelque part hors des répertoires man lib et exécutez:

 LD_PRELOAD='mylibc.so anotherlib.so' program
 

Voir: l'article de Wikipedia

Answer 3

Si vous examinez attentivement la deuxième sortie, vous constaterez que le nouvel emplacement des bibliothèques est utilisé. Peut-être y a-t-il encore des bibliothèques manquantes qui font partie de la glibc.

Je pense aussi que toutes les bibliothèques utilisées par votre programme devraient être compilées avec cette version de glibc. Si vous avez accès au code source du programme, une nouvelle compilation semble être la meilleure solution.