[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)



Le mardi 02 mai 2023 à 02:18 +0200, roger.tarani@free.fr a écrit :
> Merci !
> 
> Je n'ai JAMAIS eu besoin d'installer spécifiquement ou de réparer la
> bibliothèque C (libc6) sur un hôte debian.
> 
> L'utilisateur a installé sa debian11 seul à partir d'une image ISO
> récente.
> Je n'ai pas accès à sa machine. Je dois lui proposer une manip
> directe, simple et efficace.
> 
> Je crois comprendre qu'il s'agit d'un problème de dynamic linker.
> Comment répare-t-on l'accès à cette bibliothèque libc qui est
> installée ?
> 
> Question bonus : que peut faire un utilisateur (juste capable de
> recopier des lignes de commande fournies) pour diagnostiquer ce qui a
> pu abîmer ce système ?
> 
> 
> Extrait de mon message initial :
> 
> //
> 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... Après vérification, ce fichier existe;
> Peut-être un problème de PATH ?...
> 
> 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.
> //

comme les liens en question semblent (si j'ai compris correctement, ce
qui reste encore à prouver) créés par l'installation du paquet libc6, 
https://packages.debian.org/bullseye/amd64/libc6/filelist

c'est pour cela que je proposais:

- de vérifier (commande: apt policy libc6) les versions disponibles
pour installation et installées de libc6.
Un exemple de problème qui pourrait survenir: que ton utilisateur se
serve de multiarch; bien que l'hôte problématique soit en architecture
amd64, il suffisait par le passé que la double architecture (multiarch)
amd64+x86 soit paramétrée pour que parfois apt soit complètement perdu
et cherche à remplacer/installer des exécutables uniquement en 32 bits
(même si les deux architectures de ces exécutables existent) sur un
système 32+64 bits. Et parfois du coup ça ne marchait plus.

- de réinstallet (sudo apt reinstall libc6) ou reparamétrer (sudo dpkg-
reconfigure libc6). En cas de multiarch il faut spécifier le paramètre
-a=architecture pour apt et un dpkg-reconfigure ne suffit pas si seule
la version 32 bits de libc6 est insyallé: il faut réinstaller la
version 64 bits.

Mais je t'emmène peut-être sur une fausse piste, et même si cette piste
était en partie judicieuse, peut-être mon exposé serait-il faux quant
aux conséquences que j'évoque, hein, donc je t'encourage quoiqu'il en
soit à pendre en compte les suggestions de Jean-Michel dans son message
:-) 



Reply to: