J'ai rencontré ce problème avec le client Oracle 11R2. Je ne sais pas si le programme d'installation d'Oracle l'a fait ou si quelqu'un l'a fait ici avant mon arrivée. Ce n'était pas 64 bits contre 32 bits, tout était 64 bits.
L'erreur était que libexpat.so.1 n'était pas un lien symbolique.
Il s'est avéré qu'il y avait deux fichiers identiques, libexpat.so.1.5.2 et libexpat.so.1 . Supprimer le fichier incriminé et en faire un lien symbolique vers la version 1.5.2 a fait disparaître l'erreur.
Il est logique que vous vouliez que le nom bien connu soit un lien symbolique vers la version actuelle. Si vous faites cela, il est moins probable que vous vous retrouviez avec une bibliothèque obsolète.
Résolu, au moins au point de la question.
J'ai cherché sur le web avant de demander, et il n'y avait pas de solution concluante, la raison pour laquelle cette erreur est :lib1.so et lib2.so ne sont pas OK, très probablement non compilées pour un PC 64, mais pour une machine 32 bits sinon lib3.so est une bibliothèque 64 bits. C'est du moins mon hypothèse.
TRÈS malheureusement, ldconfig ne donne pas de message d'erreur propre informant qu'il n'a pas pu charger la bibliothèque, il ne fait que pomper :
ldconfig :/folder_where_the_wicked_lib_is/ n'est pas un lien symbolique
J'ai résolu ce problème en supprimant les bibliothèques non trouvées par ldd sur le binaire. Maintenant, il est plus facile que je sache où se situe le problème.
Ma version de ld :GNU ld version 2.20.51, et je ne sais pas si une version plus récente a un meilleur message pour ses utilisateurs.
Merci.
J'ai simplement exécuté la commande ci-dessous :
export LD_LIBRARY_PATH=/usr/lib/
Maintenant ça marche bien.