Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #35093

Re: Looking up .so file failure

Path csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From Martin Gregorie <martin@address-in-sig.invalid>
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 <nmu171$1r2$1@dont-email.me> (permalink)
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

Show key headers only | View raw


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       |

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Looking up .so file failure James <hslee911@yahoo.com> - 2016-07-22 12:02 -0700
  Re: Looking up .so file failure Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-22 20:54 +0000
  Re: Looking up .so file failure Nigel Wade <nmw@local.domain> - 2016-07-25 11:40 +0100

csiph-web