Posterior a mirar en diversos repositorios y foros de internet al concluir descubrimos la respuesta que te mostraremos más adelante.
Solución:
Me encontré con este problema con el cliente Oracle 11R2. No estoy seguro si el instalador de Oracle hizo esto o si alguien lo hizo aquí antes de que yo llegara. No era de 64 bits frente a 32 bits, todo era de 64 bits.
el error fue que libexpat.so.1 no era un vínculo simbólico.
Resultó que había dos archivos idénticos, libexpat.so.1.5.2 y libexpat.so.1. Eliminar el archivo ofensivo y convertirlo en un enlace simbólico a la versión 1.5.2 hizo que el error desapareciera.
Tiene sentido que desee que el nombre conocido sea un enlace simbólico a la versión actual. Si hace esto, es menos probable que termine con una biblioteca obsoleta.
Resuelto, al menos en el punto de la pregunta.
Busqué en la web antes de preguntar, y no hubo una solución concluyente, la razón por la cual este error es: lib1.so y lib2.so no están bien, muy probablemente no están compilados para una PC de 64 bits, sino para una máquina de 32 bits. lib3.so es una biblioteca de 64 bits. Al menos esa es mi hipótesis.
MUY lamentablemente, ldconfig no da un mensaje de error limpio que informa que no pudo cargar la biblioteca, solo bombea:
ldconfig: /folder_where_the_wicked_lib_is/ no es un enlace simbólico
Resolví esto cuando eliminé las bibliotecas no encontradas por ldd sobre el binario. Ahora es más fácil que sepa dónde está el problema.
Mi versión ld: GNU ld versión 2.20.51, y no sé si una versión más reciente tiene un mejor mensaje para sus usuarios.
Gracias.
Simplemente ejecuté el siguiente comando:
export LD_LIBRARY_PATH=/usr/lib/
Ahora está funcionando bien.
Te mostramos comentarios y valoraciones
Si haces scroll puedes encontrar las interpretaciones de otros usuarios, tú asimismo eres capaz mostrar el tuyo si te apetece.