Sur ue OpenSuse 12.3, je compile un code C utilisant la libglut
(#include <GL/glut.h>) sans message d'erreur. La commande d'édition
de liens précise -lglut, comme il se doit, et l'exécutable est produit.
Mais quand je le lance, il y a un problème :
<pgm>: error while loading shared libraries: libglut.so.3: cannot
open shared object file: No such file or directory
Il semble que le compilateur sache où trouver glut.h ainsi que la libglut.so*,
mais que ld ne sache pas trouver libglut.so* ?
Pour compliquer les choses, find ne trouve ni l'un ni l'autre :
find / -name glut.h 2> /dev/null
<nada>
find / -name "libglut*" 2> /dev/null
/var/cache/zypp/packages/repo-oss/suse/x86_64/ libglut3-2.8.0-7.1.1.x86_64.rpm
La présence du rpm, outre le fait que le compilo trouve ses ressources,
indique la libglut3 a pourtant bien été installée.
Quelqu'un aurait une idée de ce qui se passe et de ce qu'il faut faire ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Dominique MICOLLET
Bonjour,
Herve Autret wrote:
Quelqu'un aurait une idée de ce qui se passe et de ce qu'il faut faire ?
Deux pistes à suivre : - ldconfig qui rafraichira les caches de ld.so pour le cas où la librairie serait présente mais ignorée parce que fraichement installée ; - ldd le_nom_de_l_executable pour en savoir un peu plus sur ce qui cloche.
Vérifier aussi un possible incohérence 32/64 bits.
Cordialement
Dominique.
Bonjour,
Herve Autret wrote:
Quelqu'un aurait une idée de ce qui se passe et de ce qu'il faut faire ?
Deux pistes à suivre :
- ldconfig qui rafraichira les caches de ld.so pour le cas où la librairie
serait présente mais ignorée parce que fraichement installée ;
- ldd le_nom_de_l_executable pour en savoir un peu plus sur ce qui cloche.
Vérifier aussi un possible incohérence 32/64 bits.
Quelqu'un aurait une idée de ce qui se passe et de ce qu'il faut faire ?
Deux pistes à suivre : - ldconfig qui rafraichira les caches de ld.so pour le cas où la librairie serait présente mais ignorée parce que fraichement installée ; - ldd le_nom_de_l_executable pour en savoir un peu plus sur ce qui cloche.
Vérifier aussi un possible incohérence 32/64 bits.
Cordialement
Dominique.
Fred
On 12/01/2014 15:45, Herve Autret wrote:
Bonjour,
Salut
Pour compliquer les choses, find ne trouve ni l'un ni l'autre : find / -name glut.h 2> /dev/null <nada> find / -name "libglut*" 2> /dev/null /var/cache/zypp/packages/repo-oss/suse/x86_64/ libglut3-2.8.0-7.1.1.x86_64.rpm
Vérifie les droits d'accès à ces fichiers. La redirection vers /dev/null empeche de voir si il y a un problème de ce coté.
sinon les fichiers sont probablement là: /usr/include/GL/glut.h /usr/lib/libglut.so.3
Si tu à fait la compilation/installation en root et le test avec un user sans droit pour lire la lib, ça peut expliquer le problème. Enfin une partie car tous les fichiers d'en-tête et les librairies doivent être lisibles par tous les utilisateurs.
On 12/01/2014 15:45, Herve Autret wrote:
Bonjour,
Salut
Pour compliquer les choses, find ne trouve ni l'un ni l'autre :
find / -name glut.h 2> /dev/null
<nada>
find / -name "libglut*" 2> /dev/null
/var/cache/zypp/packages/repo-oss/suse/x86_64/ libglut3-2.8.0-7.1.1.x86_64.rpm
Vérifie les droits d'accès à ces fichiers. La redirection vers
/dev/null empeche de voir si il y a un problème de ce coté.
sinon les fichiers sont probablement là:
/usr/include/GL/glut.h
/usr/lib/libglut.so.3
Si tu à fait la compilation/installation en root et le test
avec un user sans droit pour lire la lib, ça peut expliquer
le problème.
Enfin une partie car tous les fichiers d'en-tête
et les librairies doivent être lisibles par tous les
utilisateurs.
Pour compliquer les choses, find ne trouve ni l'un ni l'autre : find / -name glut.h 2> /dev/null <nada> find / -name "libglut*" 2> /dev/null /var/cache/zypp/packages/repo-oss/suse/x86_64/ libglut3-2.8.0-7.1.1.x86_64.rpm
Vérifie les droits d'accès à ces fichiers. La redirection vers /dev/null empeche de voir si il y a un problème de ce coté.
sinon les fichiers sont probablement là: /usr/include/GL/glut.h /usr/lib/libglut.so.3
Si tu à fait la compilation/installation en root et le test avec un user sans droit pour lire la lib, ça peut expliquer le problème. Enfin une partie car tous les fichiers d'en-tête et les librairies doivent être lisibles par tous les utilisateurs.
Lucas Levrel
Le 13 janvier 2014, Fred a écrit :
Pour compliquer les choses, find ne trouve ni l'un ni l'autre : find / -name glut.h 2> /dev/null <nada> find / -name "libglut*" 2> /dev/null /var/cache/zypp/packages/repo-oss/suse/x86_64/ libglut3-2.8.0-7.1.1.x86_64.rpm
sinon les fichiers sont probablement là: /usr/include/GL/glut.h /usr/lib/libglut.so.3
Je n'ai pas ce paquet, mais "rpm -ql libglut3" devrait dire où sont ces fichiers. (Ou dans Yast, "liste de fichiers".)
-- LL Eν οιδα οτι ουδεν οιδα (Σωκρατης)
Le 13 janvier 2014, Fred a écrit :
Pour compliquer les choses, find ne trouve ni l'un ni l'autre :
find / -name glut.h 2> /dev/null
<nada>
find / -name "libglut*" 2> /dev/null
/var/cache/zypp/packages/repo-oss/suse/x86_64/
libglut3-2.8.0-7.1.1.x86_64.rpm
sinon les fichiers sont probablement là:
/usr/include/GL/glut.h
/usr/lib/libglut.so.3
Je n'ai pas ce paquet, mais "rpm -ql libglut3" devrait dire où sont ces
fichiers. (Ou dans Yast, "liste de fichiers".)
Pour compliquer les choses, find ne trouve ni l'un ni l'autre : find / -name glut.h 2> /dev/null <nada> find / -name "libglut*" 2> /dev/null /var/cache/zypp/packages/repo-oss/suse/x86_64/ libglut3-2.8.0-7.1.1.x86_64.rpm
sinon les fichiers sont probablement là: /usr/include/GL/glut.h /usr/lib/libglut.so.3
Je n'ai pas ce paquet, mais "rpm -ql libglut3" devrait dire où sont ces fichiers. (Ou dans Yast, "liste de fichiers".)
-- LL Eν οιδα οτι ουδεν οιδα (Σωκρατης)
Herve Autret
Bonjour
Avec délai : merci à tous pour vos réponses
Dominique MICOLLET wrote:
Deux pistes à suivre : - ldconfig qui rafraichira les caches de ld.so pour le cas où la librairie serait présente mais ignorée parce que fraichement installée ;
Nope : le pb persiste après reboot (et même moult reboots).
- ldd le_nom_de_l_executable pour en savoir un peu plus sur ce qui cloche.
SI je réinstalle cette distro ET que le défaut réapparaît, je cherche de ce côté.
Vérifier aussi un possible incohérence 32/64 bits.
Pas impossible en effet : j'ai installé une openSUSE 32 bits dans un VirtualBox idoine et mon appli fonctionne. En fait j'ai réinstallé différents systèmes sur le portable en cause (un DELL Latitude 820 ; 64 bits) avant d'avoir pris assez de temps pour chercher plus avant l'origine du pb, mais j'explorerai cette piste le cas échéant.
à + -- Hervé
Bonjour
Avec délai : merci à tous pour vos réponses
Dominique MICOLLET wrote:
Deux pistes à suivre :
- ldconfig qui rafraichira les caches de ld.so pour le cas où la
librairie serait présente mais ignorée parce que fraichement
installée ;
Nope : le pb persiste après reboot (et même moult reboots).
- ldd le_nom_de_l_executable pour en savoir un peu plus sur ce qui
cloche.
SI je réinstalle cette distro ET que le défaut réapparaît, je cherche de
ce côté.
Vérifier aussi un possible incohérence 32/64 bits.
Pas impossible en effet : j'ai installé une openSUSE 32 bits dans un
VirtualBox idoine et mon appli fonctionne. En fait j'ai réinstallé
différents systèmes sur le portable en cause (un DELL Latitude 820 ; 64
bits) avant d'avoir pris assez de temps pour chercher plus avant
l'origine du pb, mais j'explorerai cette piste le cas échéant.
Deux pistes à suivre : - ldconfig qui rafraichira les caches de ld.so pour le cas où la librairie serait présente mais ignorée parce que fraichement installée ;
Nope : le pb persiste après reboot (et même moult reboots).
- ldd le_nom_de_l_executable pour en savoir un peu plus sur ce qui cloche.
SI je réinstalle cette distro ET que le défaut réapparaît, je cherche de ce côté.
Vérifier aussi un possible incohérence 32/64 bits.
Pas impossible en effet : j'ai installé une openSUSE 32 bits dans un VirtualBox idoine et mon appli fonctionne. En fait j'ai réinstallé différents systèmes sur le portable en cause (un DELL Latitude 820 ; 64 bits) avant d'avoir pris assez de temps pour chercher plus avant l'origine du pb, mais j'explorerai cette piste le cas échéant.
à + -- Hervé
Dominique MICOLLET
Bonjour,
Herve Autret wrote:
Nope : le pb persiste après reboot (et même moult reboots).
Je ne parierai pas grand chose sur le fait que le reboot active automatiquement ld.so.
Cordialement
Dominique.
Bonjour,
Herve Autret wrote:
Nope : le pb persiste après reboot (et même moult reboots).
Je ne parierai pas grand chose sur le fait que le reboot active
automatiquement ld.so.
Nope : le pb persiste après reboot (et même moult reboots).
Je ne parierai pas grand chose sur le fait que le reboot active automatiquement ld.so.
Grr. faute de frappe.
ld.so => ldconfig
Cordialement
Dominique.
Herve Autret
Le Mon, 27 Jan 2014 09:07:10 +0100, Dominique MICOLLET a écrit:
bonjour,
Dominique MICOLLET :
Nope : le pb persiste après reboot (et même moult reboots).
Je ne parierai pas grand chose sur le fait que le reboot active automatiquement [ldconfig]
Tu veux dire : sur une distro tordue ? C'est juste ! Sur mon fidèle poste de travail, je tape: find /etc/rc.d -exec grep ldconfig {} ; -ls J'obtiens : if [ -x /sbin/ldconfig ]; then echo "Updating shared library links: /sbin/ldconfig &" /sbin/ldconfig &
[emplacement, droits, inode, date] /etc/rc.d/rc.M Donc ldconfig est invoqué au démarrage (s'il existe et est exécutable, d'accord mais passons.).
Dans l'openSUSE 32 bits (celle qui est sous VirtualBox), la même commande donne cette curiosité : elle trouve la ligne /etc/init.d/boot.ldconfig start dans /etc/init.d/nfs
Donc il faut lancer nfs pour que la ligne soit exécutée, ce qui ne change pas grand'chose car le fichier /etc/init.d/boot.ldconfig n'existe pas.
Bon, je crois que j'ai passé assez de temps avec cette distro, donc les tests dont je parlais dans mon post précédent vont devoir attendre un certain temps. Jusqu'à la prochaine version, s'il me reprend des velléités de migration. Peut-être.
à + et merci encore pour les réponses. -- Hervé
Le Mon, 27 Jan 2014 09:07:10 +0100, Dominique MICOLLET a écrit:
bonjour,
Dominique MICOLLET :
Nope : le pb persiste après reboot (et même moult reboots).
Je ne parierai pas grand chose sur le fait que le reboot active
automatiquement [ldconfig]
Tu veux dire : sur une distro tordue ? C'est juste ! Sur mon fidèle poste
de travail, je tape:
find /etc/rc.d -exec grep ldconfig {} ; -ls
J'obtiens :
if [ -x /sbin/ldconfig ]; then
echo "Updating shared library links: /sbin/ldconfig &"
/sbin/ldconfig &
[emplacement, droits, inode, date] /etc/rc.d/rc.M
Donc ldconfig est invoqué au démarrage (s'il existe et est exécutable,
d'accord mais passons.).
Dans l'openSUSE 32 bits (celle qui est sous VirtualBox), la même commande
donne cette curiosité : elle trouve la ligne
/etc/init.d/boot.ldconfig start
dans /etc/init.d/nfs
Donc il faut lancer nfs pour que la ligne soit exécutée, ce qui ne change
pas grand'chose car le fichier /etc/init.d/boot.ldconfig n'existe pas.
Bon, je crois que j'ai passé assez de temps avec cette distro, donc les
tests dont je parlais dans mon post précédent vont devoir attendre un
certain temps. Jusqu'à la prochaine version, s'il me reprend des
velléités de migration. Peut-être.
Le Mon, 27 Jan 2014 09:07:10 +0100, Dominique MICOLLET a écrit:
bonjour,
Dominique MICOLLET :
Nope : le pb persiste après reboot (et même moult reboots).
Je ne parierai pas grand chose sur le fait que le reboot active automatiquement [ldconfig]
Tu veux dire : sur une distro tordue ? C'est juste ! Sur mon fidèle poste de travail, je tape: find /etc/rc.d -exec grep ldconfig {} ; -ls J'obtiens : if [ -x /sbin/ldconfig ]; then echo "Updating shared library links: /sbin/ldconfig &" /sbin/ldconfig &
[emplacement, droits, inode, date] /etc/rc.d/rc.M Donc ldconfig est invoqué au démarrage (s'il existe et est exécutable, d'accord mais passons.).
Dans l'openSUSE 32 bits (celle qui est sous VirtualBox), la même commande donne cette curiosité : elle trouve la ligne /etc/init.d/boot.ldconfig start dans /etc/init.d/nfs
Donc il faut lancer nfs pour que la ligne soit exécutée, ce qui ne change pas grand'chose car le fichier /etc/init.d/boot.ldconfig n'existe pas.
Bon, je crois que j'ai passé assez de temps avec cette distro, donc les tests dont je parlais dans mon post précédent vont devoir attendre un certain temps. Jusqu'à la prochaine version, s'il me reprend des velléités de migration. Peut-être.
à + et merci encore pour les réponses. -- Hervé
Dominique MICOLLET
Bonjour,
Herve Autret wrote:
Tu veux dire : sur une distro tordue ? C'est juste ! Sur mon fidèle poste de travail, je tape: find /etc/rc.d -exec grep ldconfig {} ; -ls
Sur mon aussi fidèle poste de travail sous Debian Wheezy, il semble que ldconfig ne soit pas activé par le reboot : je n'en trouve pas de trace dans /etc/init.d.
La remise à jour du cache ld.so.cache semble donc très dépendante de la distribution choisie.
Cordialement
Dominique.
Bonjour,
Herve Autret wrote:
Tu veux dire : sur une distro tordue ? C'est juste ! Sur mon fidèle poste
de travail, je tape:
find /etc/rc.d -exec grep ldconfig {} ; -ls
Sur mon aussi fidèle poste de travail sous Debian Wheezy, il semble que
ldconfig ne soit pas activé par le reboot : je n'en trouve pas de trace dans
/etc/init.d.
La remise à jour du cache ld.so.cache semble donc très dépendante de la
distribution choisie.
Tu veux dire : sur une distro tordue ? C'est juste ! Sur mon fidèle poste de travail, je tape: find /etc/rc.d -exec grep ldconfig {} ; -ls
Sur mon aussi fidèle poste de travail sous Debian Wheezy, il semble que ldconfig ne soit pas activé par le reboot : je n'en trouve pas de trace dans /etc/init.d.
La remise à jour du cache ld.so.cache semble donc très dépendante de la distribution choisie.
Cordialement
Dominique.
Lucas Levrel
Le 27 janvier 2014, Herve Autret a écrit :
Nope : le pb persiste après reboot (et même moult reboots).
Je ne parierai pas grand chose sur le fait que le reboot active automatiquement [ldconfig]
Tu veux dire : sur une distro tordue ? C'est juste !
Pourquoi ldconfig devrait-il être lancé à chaque boot alors qu'il est lancé après chaque installation de paquets ?
je tape: find /etc/rc.d -exec grep ldconfig {} ; -ls
OpenSUSE 12.3 n'utilise-t-elle pas systemd ? (La 13.1 oui.)
-- LL Eν οιδα οτι ουδεν οιδα (Σωκρατης)
Le 27 janvier 2014, Herve Autret a écrit :
Nope : le pb persiste après reboot (et même moult reboots).
Je ne parierai pas grand chose sur le fait que le reboot active
automatiquement [ldconfig]
Tu veux dire : sur une distro tordue ? C'est juste !
Pourquoi ldconfig devrait-il être lancé à chaque boot alors qu'il est
lancé après chaque installation de paquets ?
je tape:
find /etc/rc.d -exec grep ldconfig {} ; -ls
OpenSUSE 12.3 n'utilise-t-elle pas systemd ? (La 13.1 oui.)
