Bonjour, J'ai un problème pour faire fonctionner un programme (truc) qui a une dépendance à libc (à libc.so.6).
Il fonctionne sans problème sur 6 hôtes debian11 sur lesquels je l'ai testé. Sans besoin d'utiliser LD_LIBRARY_PATH. Il ne fonctionne pas sur l'hôte debian11 configuré de zéro par un utilisateur peu coopératif qui attend que "ça marche tout seul" sans se poser de telles questions. Voici les dépendances de l'exécutable $ ldd truc linux-vdso.so.1 (0x00007ffef8f73000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4f87607000) /lib64/ld-linux-x86-64.so.2 (0x00007f4f87813000) L'hôte (Architecture : x86_64) et l'exécutable (En-tête ELF: Classe: ELF64) sont en 64 bits... Sur l'hôte qui pose problème : - libc.so.6 est bien présent. Et est donc inaccessible à l'exécutable. - la commande ldconfig est introuvable. J'attends de savoir si /usr/sbin/ldconfig existe. Sur un hôte qui sert correctement libc.so.6 au même exécutable, il y a les liens symboliques suivants vers ld-2.31.so lrwxrwxrwx 1 root root 32 Apr 19 23:17 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so -rwxr-xr-x 1 root root 177928 Apr 19 23:17 /lib/x86_64-linux-gnu/ld-2.31.so lrwxrwxrwx 1 root root 10 Apr 19 23:17 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 -> ld-2.31.so Cela manque sur l'hôte qui pose problème. Je n'ai JAMAIS eu besoin de gérer cette dépendance occasionnelle du point de vue de l'utilisateur. Peut-être qu'installer gcc réglerait le problème ou utiliser un 'dpkg reconfigure' ou créer à la main un lien symbolique. Je crains de m'égarer en ne respectant pas la manière de faire ça sur un hôte debian (cad configurer et utiliser le dynamic loader, si j'ai bien compris). Comment traiter _propremement_ ce problème ? Merci.
