J’ai eu a installer une application développée en Java sur une version Red Hat Entreprise Linux 5.2 Server avec un JRE 1.5.0.17 et j’ai eu quelques difficultés à réaliser cette opération mais j’ai finalement réussi suite à quelques recherches (ceci doit être valable pour la majorité des distributions Linux).
Si vous avec ce type d’erreur dans une console lors de l’installation ou de l’execution d’une application java:
$ ./MonAppli
awk: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/bin/ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/home/user1/soft-6.1-911/jre/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
La cause :
Sans rentrer dans le détail, ce problème survient lors d’une incompatibilité de l’installateur du JRE (Java Run-time Environment) avec certaines librairies système.
La solution :
La commande à effectuer va consister à afficher le contenu de MonAppli.bak, l’envoyer à la commande sed qui lui va mettre en commentaire (grâce au #) la ligne export LD_ASSUME_KERNEL.
export LD_ASSUME_KERNEL mets en place une variable d’environnement qui va spécifier la version du noyau à utiliser (2.4 ou 2.6).
Il faut lancer les commandes suivantes dans une console ou un terminal dans le même repertoire où vous avez extrait l’installateur du logiciel ou de son executable (remplacer MonAppli par le nom de votre logiciel):
$ cp MonAppli MonAppli.bak
$ cat MonAppli.bak | sed "s/export LD_ASSUME_KERNEL/#xport LD_ASSUME_KERNEL/" > MonAppli
Pensez à rendre votre fichier executable au cas ou:
$ chmod +x MonAppli
Et executez-le:
$ ./MonAppli
Suite à l’installation de votre application ou de son execution, si ça fonctionne, vous pouvez supprimer les fichiers .bak.
$ rm MonAppli.bak
J’ajoute un petit complément à ce billet car j’ai été confronté à un autre souci qui m’a finalement fait perdre pas mal de temps (sous Fedora 10)…
Si suite aux petites manipulations vu ci-dessus vous rencontrez une erreur du type ou quelque chose s’en rapprochant:
Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)
Stack Trace:
java.lang.UnsatisfiedLinkError: /tmp/install.dir.4072/Linux/resource/jre/lib/i386/xawt/libmawt.so: libXext.so.6: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1647)
at java.lang.Runtime.load0(Runtime.java:769)
at java.lang.System.load(System.java:967)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1668)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)
at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)
at java.awt.Component.<clinit>(Component.java:545)
at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)
at com.zerog.ia.installer.LifeCycleManager.h(DashoA8113)
at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)
at com.zerog.ia.installer.Main.main(DashoA8113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.zerog.lax.LAX.launch(DashoA8113)
at com.zerog.lax.LAX.main(DashoA8113)
This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)
Commencez par faire un locate de la lib qui pose problème, ici libXext.so.6 :
$ locate libXext.so.6
dans le cas ou celà fonctionne, vous devriez avoir sous Fedora 10 :
/usr/lib64/libXext.so.6 /usr/lib64/libXext.so.6.4.0
Si rien, n’apparait, c’est que cette librairie n’est effectivement pas présente (pour on ne sait quelle raison car la fois precedente ça avait fonctionné…) et qu’il va falloir l’installer à la mimine et là c’est rendez-vous sur https://rpmfind.net/ :
un petit search de la librairie vous aidera souvent :
https://rpmfind.net/linux/rpm2html/search.php?query=libXext.so.6
Et ce pour un grand nombre de distributions basées sur les RPM.
Bonjour,
J’ai rencontré exactement l’erreur citée en fin de tuto, j’ai fais un locate libXext.so.6 et la commande m’a retourné ceci :
/usr/X11R6/lib64/libXext.so.6.4
/usr/X11R6/lib64/libXext.so.6
Petite précision, je suis sous RedHat enterprise AS4.6 64 bits.
Que faut-il faire pour ne plus avoir l’erreur alors que la librairie est bien présente ?
Merci d’avance
rien a dire toujours le meilleur du web!