Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
> Le 5 mai 2023 à 17:30, Hugues Larrive a écrit : > > Bonjour, > > --- Original Message --- >> Le mercredi 3 mai 2023 à 22:33, RogerT a écrit : >> >> >> je reformule : il y a des problèmes sur aarch64 INEXISTANTS sur x86_64 >> Le 3 mai 2023 à 20:09, RogerT roger.tar...@free.fr a écrit : >>> >>> Ça a compilé. >>> Ça tourne sur architecture aarch64. >>> >>> Mais il y a des problèmes avec certaines dépendances à des fonctions du >>> shell ou à systemd (inexistantes sur x86_64) que je dois régler. >>> > > Quels sont les problèmes ? Y a-t-il des messages d'erreur ? Quelles fonctions > du shell sont concernées ? > Les différences les plus flagrantes entre les 2 architectures sont l'absence > d'ACPI et de DMI remplacés par devicetree sur arm. Les arm sont souvent des > SoC donc les périphériques sont organisés différemment, par exemple des > périphériques qu'on trouve habituellement sur le bus PCI comme l'ethernet, la > video ou le multimédia peuvent ne pas s'y trouver donc les outils > habituellement utilisés sur PC pour identifier le matériel comme lspci ou > lshw ne donneront pas les résultats attendus... Tout ce qui concerne l'ACPI > et EFI (les interaction avec le firmware) peut poser problème aussi. > > De quel genre de programme s'agit-il ? Bonjour, Après que l’utilisateur, qui a décidé d’installer un hôte debian 11 tout seul sans mon aide, ait enfin corrigé les problèmes qu’il avait seul causés, le logiciel compilé pour aarch64 (voir référence communiquée pour savoir comment faire) tourne sans erreur perceptible à ce jour (ex de pb causé : avec apt, en laissant le chemin du cdrom dans /etc/apt/sources.list ). C’est un logiciel d’automatisation qui utilise beaucoup de commandes habituelles accessibles après installation avec apt et assure le contrôle de flot. Et vérifie en particulier l’état de l’hôte, si les paquets requis sont installés et disponibles et les installe si nécessaire. Toute commande qui tourne sur l’architecture visée doit tourner avec ce logiciel qui les appelle. Question subsidiaire : existe-t-il un outil en CLI pour tester que l’hôte mis à disposition par l’utilisateur est correctement configuré ? (Cf. « Les 12-20 trucs à faire après avoir installé un système debian »). > > @+ > Hugues > Le 3 mai 2023 à 09:40, didier gaumet didier.gau...@gmail.com a écrit : Le mercredi 03 mai 2023 à 03:18 +0200, roger.tar...@free.fr a écrit : [...] > Est-ce aussi simple que ça ou y a-t-il des pièges sournois dans la > cross-compilation ? Je n'y connais rien vu que je ne construis pas/plus d'exécutables et encore moins par cross-compilation mais le wiki Debian a un article sur les différentes possibilités et bonnes pratiques de cross-compilation en environnement Debian: https://wiki.debian.org/CrossCompiling publickey - hlarrive@pm.me - 0xE9429B87.asc Description: Binary data signature.asc Description: Binary data
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Bonjour, --- Original Message --- Le mercredi 3 mai 2023 à 22:33, RogerT a écrit : > > > je reformule : il y a des problèmes sur aarch64 INEXISTANTS sur x86_64 > > > Le 3 mai 2023 à 20:09, RogerT roger.tar...@free.fr a écrit : > > > > Ça a compilé. > > Ça tourne sur architecture aarch64. > > > > Mais il y a des problèmes avec certaines dépendances à des fonctions du > > shell ou à systemd (inexistantes sur x86_64) que je dois régler. > > Quels sont les problèmes ? Y a-t-il des messages d'erreur ? Quelles fonctions du shell sont concernées ? Les différences les plus flagrantes entre les 2 architectures sont l'absence d'ACPI et de DMI remplacés par devicetree sur arm. Les arm sont souvent des SoC donc les périphériques sont organisés différemment, par exemple des périphériques qu'on trouve habituellement sur le bus PCI comme l'ethernet, la video ou le multimédia peuvent ne pas s'y trouver donc les outils habituellement utilisés sur PC pour identifier le matériel comme lspci ou lshw ne donneront pas les résultats attendus... Tout ce qui concerne l'ACPI et EFI (les interaction avec le firmware) peut poser problème aussi. De quel genre de programme s'agit-il ? @+ Hugues > > > Le 3 mai 2023 à 09:40, didier gaumet didier.gau...@gmail.com a écrit : > > > > > > Le mercredi 03 mai 2023 à 03:18 +0200, roger.tar...@free.fr a écrit : > > > [...] > > > > > > > Est-ce aussi simple que ça ou y a-t-il des pièges sournois dans la > > > > cross-compilation ? > > > > > > Je n'y connais rien vu que je ne construis pas/plus d'exécutables et > > > encore moins par cross-compilation mais le wiki Debian a un article sur > > > les différentes possibilités et bonnes pratiques de cross-compilation en > > > environnement Debian: > > > https://wiki.debian.org/CrossCompiling publickey - hlarrive@pm.me - 0xE9429B87.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
je reformule : il y a des problèmes sur aarch64 INEXISTANTS sur x86_64 > Le 3 mai 2023 à 20:09, RogerT a écrit : > > Ça a compilé. > Ça tourne sur architecture aarch64. > > Mais il y a des problèmes avec certaines dépendances à des fonctions du shell > ou à systemd (inexistantes sur x86_64) que je dois régler. > > >> Le 3 mai 2023 à 09:40, didier gaumet a écrit : >> >> Le mercredi 03 mai 2023 à 03:18 +0200, roger.tar...@free.fr a écrit : >> [...] >>> Est-ce aussi simple que ça ou y a-t-il des pièges sournois dans la >>> cross-compilation ? >> >> Je n'y connais rien vu que je ne construis pas/plus d'exécutables et encore >> moins par cross-compilation mais le wiki Debian a un article sur les >> différentes possibilités et bonnes pratiques de cross-compilation en >> environnement Debian: >> https://wiki.debian.org/CrossCompiling >> >>
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Ça a compilé. Ça tourne sur architecture aarch64. Mais il y a des problèmes avec certaines dépendances à des fonctions du shell ou à systemd (inexistantes sur x86_64) que je dois régler. > Le 3 mai 2023 à 09:40, didier gaumet a écrit : > > Le mercredi 03 mai 2023 à 03:18 +0200, roger.tar...@free.fr a écrit : > [...] > > Est-ce aussi simple que ça ou y a-t-il des pièges sournois dans la > > cross-compilation ? > > Je n'y connais rien vu que je ne construis pas/plus d'exécutables et encore > moins par cross-compilation mais le wiki Debian a un article sur les > différentes possibilités et bonnes pratiques de cross-compilation en > environnement Debian: > https://wiki.debian.org/CrossCompiling > >
Re: Re : Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Le mercredi 03 mai 2023 à 03:18 +0200, roger.tar...@free.fr a écrit : [...] > Est-ce aussi simple que ça ou y a-t-il des pièges sournois dans la > cross-compilation ? Je n'y connais rien vu que je ne construis pas/plus d'exécutables et encore moins par cross-compilation mais le wiki Debian a un article sur les différentes possibilités et bonnes pratiques de cross-compilation en environnement Debian: https://wiki.debian.org/CrossCompiling
Re: Re : Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Oui, en effet. Installer un cross-compilateur : $ sudo apt install gcc make gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu Compiler pour aarch64 un pgm helloworld.c : $ aarch64-linux-gnu-gcc helloworld.c -o helloworld-aarch64 -static Voir https://jensd.be/1126/linux/cross-compiling-for-arm-or-aarch64-on-debian-or-ubuntu J'ai envoyé à l'utilisateur un fichier cross-compilé pour aarch64 (depuis un hôte x86_64) pour savoir si ça s'exécute. A suivre. Est-ce aussi simple que ça ou y a-t-il des pièges sournois dans la cross-compilation ? - Mail original - De: "didier gaumet" À: "Liste Debian" Envoyé: Mardi 2 Mai 2023 20:14:55 Objet: Re: Re : Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11) Le 02/05/2023 à 15:23, Hugues Larrive a écrit : > --- Original Message --- > Le mardi 2 mai 2023 à 13:11, Bernard Schoenacker > a écrit : > > >> Je crois qu'on chauffe. >> L'hôte est une VM Parallels et il me revient qu'elle pourrait être une >> machine multiarchitecture... > > Parallels c'est de la virtualisation pour Mac donc sur les systèmes actuels > (apple silicon) l'OS invité est en architecture ARM (aarch64). > > Dans ce cas 2 possibilités : > - utiliser une version du programme compilée pour cette architecture s'il en > existe ou que le source est disponible ; > - multi-arch. > > @+ > Hugues Ah, là, je crois que ton intervention va permettre de clarifier la situation vite et bein :-) (moi j'avais même pas tilté que Parallels c'est pour Mac et que les Mac ont maintenant des puces arm64)
Re: Re : Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Le 02/05/2023 à 15:23, Hugues Larrive a écrit : --- Original Message --- Le mardi 2 mai 2023 à 13:11, Bernard Schoenacker a écrit : Je crois qu'on chauffe. L'hôte est une VM Parallels et il me revient qu'elle pourrait être une machine multiarchitecture... Parallels c'est de la virtualisation pour Mac donc sur les systèmes actuels (apple silicon) l'OS invité est en architecture ARM (aarch64). Dans ce cas 2 possibilités : - utiliser une version du programme compilée pour cette architecture s'il en existe ou que le source est disponible ; - multi-arch. @+ Hugues Ah, là, je crois que ton intervention va permettre de clarifier la situation vite et bein :-) (moi j'avais même pas tilté que Parallels c'est pour Mac et que les Mac ont maintenant des puces arm64)
Re : Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
--- Original Message --- Le mardi 2 mai 2023 à 13:11, Bernard Schoenacker a écrit : > Je crois qu'on chauffe. > L'hôte est une VM Parallels et il me revient qu'elle pourrait être une > machine multiarchitecture... Parallels c'est de la virtualisation pour Mac donc sur les systèmes actuels (apple silicon) l'OS invité est en architecture ARM (aarch64). Dans ce cas 2 possibilités : - utiliser une version du programme compilée pour cette architecture s'il en existe ou que le source est disponible ; - multi-arch. @+ Hugues publickey - hlarrive@pm.me - 0xE9429B87.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
- Mail original -
De: "roger tarani"
À: "Liste Debian"
Envoyé: Mardi 2 Mai 2023 11:08:39
Objet: Re: Problème pour servir à un exécutable sa dépendance à libc.so.6
(debian 11)
Je crois qu'on chauffe.
L'hôte est une VM Parallels et il me revient qu'elle pourrait être une machine
multiarchitecture...
Je crois avoir vu ça dans le résultat d'une commande.
Je n'y suis pas habitué. Et j'ai toujours installé des OS debian 64 bits.
Quelle serait la commande qui permet de savoir exactement s'il y a une
multiarchitecture (qui aurait trompé apt) ?
(je ne crois pas que ce soit lscpu ni hostnamectl)
apt policy libc6 ?
Rappel : je ne peux pas tâtonner auprès de l'utilisateur en lui demandant de
saisir de nombreuses commandes. Il doit entrer une commande pour diagnostiquer
et une commande pour traiter le pb.
Merci.
Bonjour Roger,
L'instruction la plus adaptée :
dpkg -l |awk '/libc6/ {print $2,$3}'
vérification de la disponibilité des paquets libc6 par rapport à la version
installée
apt-cache show $(dpkg -l |awk '/libc6/ {print $2}') |grep Filename
pour le fichier sources.list :
deb [trusted=Yes, arch=amd64,i386] https://deb.debian.org/debian-security/
stable-security main contrib non-free non-free-firmware
il est également possible d'exclure les architectures (exemple) :
deb [trusted=Yes, arch=amd64,i386 arch-=armel,arm32]
https://deb.debian.org/debian-security/ stable-security main contrib non-free
non-free-firmware
Remarque : consulter la doc du manuel concernant le fichier sources.list
https://manpages.debian.org/jessie/apt/sources.list.5.en.html
pour télécharger un paquet à la main, prendre le fichier sources.list (URLs) :
https://deb.debian.org/debian-security
le dépôt du paquet :
pool/main/g/glibc/libc6-dev_2.36-9_amd64.deb
raccrocher les wagons :
https://deb.debian.org/debian-securitypool/main/g/glibc/libc6-dev_2.36-9_amd64.deb
et employer wget :
wget -c -O ~/Téléchargements/libc6-dev_2.36-9_amd64.deb
https://deb.debian.org/debian-securitypool/main/g/glibc/libc6-dev_2.36-9_amd64.deb
cd ~/Téléchargements
sudo apt install -y ./libc6-dev_2.36-9_amd64.deb
attention, c'est un exemple
Merci pour ton aimable attention
Bien à toi
Bernard
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Le mardi 02 mai 2023 à 11:08 +0200, roger.tar...@free.fr a écrit : > Je crois qu'on chauffe. > L'hôte est une VM Parallels et il me revient qu'elle pourrait être > une machine multiarchitecture... > Je crois avoir vu ça dans le résultat d'une commande. > Je n'y suis pas habitué. Et j'ai toujours installé des OS debian 64 > bits. > > Quelle serait la commande qui permet de savoir exactement s'il y a > une multiarchitecture (qui aurait trompé apt) ? (je suis en pur amd64, pas multiarch) didier@hp-notebook14:~$ dpkg --print-architecture amd64 > (je ne crois pas que ce soit lscpu ni hostnamectl) > > apt policy libc6 ? dans mon cas ça ne montre pas l'architecture i386 vu que je suis en pur amd64 mais je suppose que les deux (32 et 64 bits) aparaîtraient dans les paquets candidats didier@hp-notebook14:~$ apt policy libc6 libc6: Installé : 2.31-13+deb11u6 Candidat : 2.31-13+deb11u6 Table de version : *** 2.31-13+deb11u6 500 500 http://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status 2.31-13+deb11u5 500 500 http://deb.debian.org/debian bullseye-updates/main amd64 Packages tu peux aussi passer par dpkg: didier@hp-notebook14:~$ dpkg -l libc6* Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi- installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais) ||/ Nom Version Architecture Description +++-=-===-- = ii libc6:amd64 2.31-13+deb11u6 amd64GNU C Library: Shared libraries un libc6-amd64(aucune description n'est disponible) ii libc6-dev:amd64 2.31-13+deb11u6 amd64GNU C Library: Development Libraries and Header Files un libc6-dev-amd64-cross (aucune description n'est disponible) un libc6.1(aucune description n'est disponible) un libc6.1-dev(aucune description n'est disponible) mais l'intérêt avec apt policy ou dpkg c'est aussi de voir si on n'a pas une ancienne version d'un programme qui traîne suite à une mise à jour incomplète d'une version majeure de Debian. Par exemple dans ton cas, on peut aussi se demander éventuellement si on n'a pas un libc6 en version 2.28 (Buster) au lieu de 2.31 (Bullseye). Au cas où tu aurais expréssément cherché sans le trouver un lien vers libc6 2.31, ceci pourrait expliquer cela. > Rappel : je ne peux pas tâtonner auprès de l'utilisateur en lui > demandant de saisir de nombreuses commandes. Il doit entrer une > commande pour diagnostiquer et une commande pour traiter le pb. > > Merci. Là, sans m'immiscer dans ta relation avec ton utilisateur (d'une part ça ne me regarde pas et de l'autre je ne connais ni la nature de votre relation ni le contexte dans lequel vous évoluez), je peux quand même te suggérer d'être coopératif dans ton suppport mais aussi de recadrer diplomatiquement: si ton utilisateur choisit d'installer et maintenir lui-même sa distribution, il accepte le cas échéant de porter la responsabilité d'une distribution trop bancale pour faire tourner une appli fournie par un tiers dans des conditions d'installations raisonnables, et accepte donc aussi la responsabilité de devoir chercher lui-même comment s'en sortir (exemple si il utilise un SGBD Oracle dont il paie le support *applicatif*, Oracle ne va pas paramétrer ou réinstaller Debian à sa place si sa distro est bancale car c'est du support *système*. Enfin c'est comme ça que je vois les choses, peut-être de manière trop simpliste)
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Je crois qu'on chauffe. L'hôte est une VM Parallels et il me revient qu'elle pourrait être une machine multiarchitecture... Je crois avoir vu ça dans le résultat d'une commande. Je n'y suis pas habitué. Et j'ai toujours installé des OS debian 64 bits. Quelle serait la commande qui permet de savoir exactement s'il y a une multiarchitecture (qui aurait trompé apt) ? (je ne crois pas que ce soit lscpu ni hostnamectl) apt policy libc6 ? Rappel : je ne peux pas tâtonner auprès de l'utilisateur en lui demandant de saisir de nombreuses commandes. Il doit entrer une commande pour diagnostiquer et une commande pour traiter le pb. Merci. - Mail original - De: "didier gaumet" À: "Liste Debian" Envoyé: Mardi 2 Mai 2023 08:21:25 Objet: 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.tar...@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 :-)
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.tar...@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 :-)
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
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. // - Mail original - De: "didier gaumet" À: "Liste Debian" Envoyé: Lundi 1 Mai 2023 10:31:09 Objet: Re: Fwd: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11) Bonjour, je réponds juste pour que tu ne te sentes pas tout seul mais mes compétences sur le sujet ne me permettent pas de t'apporter une contribution pertinente ;-) quelques points hypothétiquement à surveiller: - peut-être reconfigurer ou réinstaller libc6 sur le poste qui pose problème puique les liens que tu cites semblent créés par ce paquet - faire un apt policy libc6 pour vérifier les versions disponibles et installées sur ce poste - peut-être vérifier si quelqu'un a joué avec Apparmor ou SElinux sur ce poste t'es pas beaucoup plus avancé, je t'avais prévenu ;-)
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Bonsoir, Le message d’erreur est : 1 : ELF not founded 1 : Syntax error : Unterminated quoted string On retrouve beaucoup de discussions sur les forums stackoverflow, etc. à ce propos (défaut d’une bibliothèque ; dissuasion de lier le so à l’exécutable, etc. ) Mais je n’ai pas trouvé de mode opératoire clair et simple pour régler ça de manière régulière, cad sans effet de bord connu ou caché. Je veux éviter de fabriquer des liens symboliques qui pourraient régler temporairement le problème avant de disparaître car la cause du problème aurait été oubliée. Merci. > Le 1 mai 2023 à 12:03, Jean-Michel OLTRA a écrit : > >Bonjour, > > > Le dimanche 30 avril 2023, roger.tar...@free.fr a écrit... > > >> Sur l'hôte qui pose problème : >> - libc.so.6 est bien présent. Et est donc inaccessible à l'exécutable. > > Bizarre, car un paquet de binaires sont liés à libc6. > Tu peux faire, par exemple : `ldd /usr/bin/ps` > > Et quand tu dis "inaccessible", finalement, ça se manifeste comment ? > > Tu pourrais utiliser strace pour tenter de voir ce qui est attendu, et pas > résolu ? > > -- > jm
Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Bonjour, Le dimanche 30 avril 2023, roger.tar...@free.fr a écrit... > Sur l'hôte qui pose problème : > - libc.so.6 est bien présent. Et est donc inaccessible à l'exécutable. Bizarre, car un paquet de binaires sont liés à libc6. Tu peux faire, par exemple : `ldd /usr/bin/ps` Et quand tu dis "inaccessible", finalement, ça se manifeste comment ? Tu pourrais utiliser strace pour tenter de voir ce qui est attendu, et pas résolu ? -- jm
Re: Fwd: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Bonjour, je réponds juste pour que tu ne te sentes pas tout seul mais mes compétences sur le sujet ne me permettent pas de t'apporter une contribution pertinente ;-) quelques points hypothétiquement à surveiller: - peut-être reconfigurer ou réinstaller libc6 sur le poste qui pose problème puique les liens que tu cites semblent créés par ce paquet - faire un apt policy libc6 pour vérifier les versions disponibles et installées sur ce poste - peut-être vérifier si quelqu'un a joué avec Apparmor ou SElinux sur ce poste t'es pas beaucoup plus avancé, je t'avais prévenu ;-)
Fwd: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Je corrige : il s'agit plutôt du dynamic _linker_ (et non dynamic loader). Pour régler le problème décrit, il s'agirait peut-être de rendre disponible /lib64/ld-linux-x86-64.so. Qu'en pensez-vous ? Quant à linux-vdso.so (virtual symbolic link to the bitness-compatible ; vDSO = virtual dynamic shared object), je ne sais pas en dire grand chose (diagnostiquer/corriger) https://man7.org/linux/man-pages/man7/vdso.7.html De: "roger tarani" À: "Liste Debian" Envoyé: Dimanche 30 Avril 2023 13:53:36 Objet: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11) 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 (0x7ffef8f73000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4f87607000) /lib64/ld-linux-x86-64.so.2 (0x7f4f87813000) 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.
Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
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 (0x7ffef8f73000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4f87607000) /lib64/ld-linux-x86-64.so.2 (0x7f4f87813000) 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.
