Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Looking up .so file failure Date: Fri, 22 Jul 2016 20:54:57 -0000 (UTC) Organization: A noiseless patient Spider Lines: 89 Message-ID: References: <3272d21a-91f3-4eb9-bebf-095966f6e8ef@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 22 Jul 2016 20:54:57 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="1890"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/A9R6w1Z+HANszlngSignvBDy5edf1s1c=" User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 3663720 git://git.gnome.org/pan2) Cancel-Lock: sha1:96EnbxEkvceE1PeDlH6vKPmXA6M= Xref: csiph.com comp.lang.java.programmer:35093 On Fri, 22 Jul 2016 12:02:20 -0700, James wrote: > Hi all, > I get this error in java application (on Linux), but not often. > > Exception in thread "main" java.lang.UnsatisfiedLinkError: > .../jdk1.6.0_14/jre/lib/i386/xawt/libmawt.so: libXext.so.6: cannot open > shared object file: No such file or directory > > However, sometimes there's no error. Apparently it is looking for > .../jdk1.6.0_14/jre/lib/i386/libawt.so and works fine. > And I thought I had an old Java version when I was running jdk1.6.0_45 ... That version is still installed but no longer used, so I was able to confirm that it has both of those library files installed: .../jdk1.6.0_45/jre/lib/i386/libawt.so .../jdk1.6.0_45/jre/lib/i386/xawt/libmawt.so But I don't know whether 1.6.0_14 is the same. All I can say is that jdk1.8.0_91 has libawt.so and libawt_xawt.so in jre/lib/i386 and does NOT have the jre/lib/i386/xawt directory, so the number, names and placement of these library files are not immutable. Does this fault: (a) always occur in the same application, or (b) has it occurred in more than one application? If (a), how old are the compiled classes and does it go away if that application's .class and/or .jar files are deleted and rebuilt? If (b), what do fsck and badblocks say about the partition where the JDK is installed? If you are running a smartd cron job, what do its reports have to say about the disk's health? As a subsidiary question, if you're not running smartd, why not? > Is there some order of looking up .so files, which can change due to > some unknown factors? > Have you got LD_LIBRARY_PATH set, and if so, is it set the same every time the failing Java application(s) are run? It is unset by default in all my runtime and development environments. There's more information about the dynamic linking loader in the dlopen manpage. LD_LIBRARY_PATH is used to change the set of directories searched by dlopen(). > What is the command to list all .so files to be used by Java > applications? > Possibly it is somewhere in the JDK documentation package. The dynamically loaded libraries issued as part of the JDK are unlikely to be used directly by an application because they're really part of the JVM and/or Java utilities included in the JDK or JRE. If the application uses JNI to access native code from a dynamically loaded library that should be specified in the application's documentation. > Was there an installation error? This java package was installed on > 32-bit linux and used by 64-bit now. > Only you can know that asnd why you're still running a 32 bit Java 1.6 version. If the application(s) used to work correctly and don't now, then the usual suspects would be either a developing hardware problem or a software incompatibility between that rather old Java version and a more recent Linux package resulting from installing a later Linux version or from a package upgrade during your periodic Linux update. That said, I haven't seen any such problem myself, and all my Java applications, some of which data back to Java 1.4 and have never been recompiled, have continued to run without problems despite successive upgrades of both the Java SDK and Linux, now at Java 1.8.0_91 and Fedora 23. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |