Java JDK chemin libjli.so manquant dans la liste des dépendances, Debian

8

Je scénarise la création de prisons chroot et une partie de cette automatisation comprend la copie de divers exécutables et de leurs dépendances dans la prison. J'utilise la ligne bash suivante pour analyser les chemins de fichiers d'une liste de dépendances (pour java, par exemple):

$ ldd `which java` | grep -o '/[^()]*'
/lib/x86_64-linux-gnu/libz.so.1
/lib/x86_64-linux-gnu/libpthread.so.0
/lib/x86_64-linux-gnu/libdl.so.2
/lib/x86_64-linux-gnu/libc.so.6
/lib64/ld-linux-x86-64.so.2

Cela fonctionne très bien pour Node.js et Python, mais lorsque j'essaie de l'exécuter javadepuis la prison, j'obtiens une erreur:

java: erreur lors du chargement des bibliothèques partagées: libjli.so: impossible d'ouvrir le fichier d'objet partagé: aucun fichier ou répertoire de ce type

Il s'avère que le chemin libjli.so est absent de la liste des dépendances ... du moins celles qui lddnous le montrent (ligne 5):

$ ldd `which java`
linux-vdso.so.1 =>  (0x00007ffff7f4d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7ac3928000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7ac370c000)
libjli.so => not found
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7ac3507000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ac317c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7ac3b48000)

J'ai trouvé le fichier ...

$ find /usr/lib -name libjli.so
/usr/lib/jvm/java-6-openjdk-amd64/lib/amd64/jli/libjli.so
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/jli/libjli.so

... mais j'aimerais savoir pourquoi il ne figure pas dans la liste ldd. Il s'agit apparemment d'une dépendance connue, mais le chemin est inconnu? Toute aide est appréciée!

Rip Leeb
la source
Question intéressante, vous pouvez essayer de poser cette question sur un forum openjdk.
Faheem Mitha
Au cas où quelqu'un trébucherait sur Google: il semble que ce soit un doublon avec unix.stackexchange.com/questions/16656 , qui contient plus d'informations (et des réponses différentes).
yshavit

Réponses:

7

Il est censé fonctionner hors de la boîte - sans jouer avec /etc/ld.so.conf* ou ldconfig - et il peut facilement le faire. Montez / proc dans votre chroot. Je le fais avec la ligne suivante dans / etc / fstab dans mon fs racine réelle:

/ proc / var / chroot / ia32 / proc aucune liaison

Le liant ainsi au réel / proc.

Par https://github.com/cedric-vincent/PRoot/issues/9 , ld-linux.so (je suppose que c'est le cas) détermine $ ORIGIN pour se substituer aux entrées RPATH de objdump -p en regardant / proc / self / EXE.

Combien de fois ai-je été mordu par cela et ai dû le redécouvrir? S'il vous plaît, ô puissant et sage Google, ramenez-moi ici rapidement la prochaine fois, afin que le futur-moi puisse réapprendre au genou du passé!

Martin Dorey
la source
1
Merci. Votre pointage /proc/self/exeétait l'indice manquant à mes côtés. Le montage /procdans mon chroot a fait l'affaire.
Tino
3

Il semble que vous devez ajouter

/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/jli

vers /etc/ld.so.conf, ou plus probablement vers un nouveau fichier dans /etc/ld.so.conf.d. Exécutez ensuite ldconfigpour mettre à jour le cache afin de lddtrouver la bibliothèque.

Pour les scripts de chroots, vous aurez probablement moins de mal à long terme à adopter une approche basée sur un paquet, en créant d'abord une installation de base (en utilisant par exemple debootstrap sur des hôtes basés sur Debian), puis en installant les paquets que vous voulez. Cela permet au gestionnaire de packages de s'occuper de tout le travail de résolution des dépendances, d'installation de tous les fichiers nécessaires et d'exécution des tâches de post-installation.

Andrew Schulman
la source
Et pouvez-vous me dire pourquoi il ne se trouvait pas dans ld.so.conf ou dans l'un des fichiers inclus? Le système d'exploitation aurait-il dû le mettre pendant l'installation?
Rip Leeb
Non, je ne le sais pas. Je peux dire que je vois le même résultat sur mon hôte Ubuntu 14.04, et pourtant java démarre bien. Il doit donc résoudre la dépendance dynamiquement au moment de l'exécution.
Andrew Schulman