Ich bin auf dieses Problem mit dem Oracle 11R2-Client gestoßen. Ich bin mir nicht sicher, ob das Oracle-Installationsprogramm dies getan hat oder jemand es hier getan hat, bevor ich angekommen bin. Es war nicht 64-Bit vs. 32-Bit, alles war 64-Bit.
Der Fehler war dieser libexpat.so.1 war kein symbolischer Link.
Es stellte sich heraus, dass es zwei identische Dateien gab, libexpat.so.1.5.2 und libexpat.so.1 . Das Entfernen der problematischen Datei und das Erstellen eines Symlinks zur Version 1.5.2 führte dazu, dass der Fehler behoben wurde.
Es ist sinnvoll, dass der bekannte Name ein Symlink zur aktuellen Version sein soll. Wenn Sie dies tun, ist es weniger wahrscheinlich, dass Sie mit einer veralteten Bibliothek enden.
Gelöst, zumindest am Punkt der Frage.
Ich habe im Web gesucht, bevor ich gefragt habe, und es gab keine schlüssige Lösung, der Grund für diesen Fehler ist:lib1.so und lib2.so sind nicht in Ordnung, sehr wahrscheinlich wurden sie nicht für einen 64-PC kompiliert, sondern für eine 32-Bit-Maschine lib3.so ist eine 64-Bit-Bibliothek. Das ist zumindest meine Hypothese.
SEHR unglücklicherweise gibt ldconfig keine saubere Fehlermeldung aus, die darüber informiert, dass die Bibliothek nicht geladen werden konnte, sondern pumpt nur:
ldconfig:/folder_where_the_wicked_lib_is/ ist kein symbolischer Link
Ich habe das gelöst, als ich die von ldd nicht gefundenen Bibliotheken über die Binärdatei entfernt habe. Jetzt ist es einfacher, dass ich weiß, wo das Problem liegt.
Meine ld-Version:GNU ld-Version 2.20.51, und ich weiß nicht, ob eine neuere Version eine bessere Botschaft für ihre Benutzer hat.
Danke.
Ich habe einfach den folgenden Befehl ausgeführt:
export LD_LIBRARY_PATH=/usr/lib/
Jetzt funktioniert es einwandfrei.