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

Groups > comp.lang.java.programmer > #35092 > unrolled thread

Looking up .so file failure

Back to article view | Back to comp.lang.java.programmer

Contents

  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

#35092 — Looking up .so file failure

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.

Is there some order of looking up .so files, which can change due to some unknown factors?

What is the command to list all .so files to be used by Java applications?

Was there an installation error? This java package was installed on 32-bit linux and used by 64-bit now. 

Thanks in advance.
James

[toc] | [next] | [standalone]

#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       |

[toc] | [prev] | [next] | [standalone]

#35133

On 22/07/16 20:02, 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

The failure indicated here is a missing libXext.so.6. This library is part of the X Window system.
jdk1.6.0_14/jre/lib/i386/xawt/libmawt.so is a 32bit libary (i386), so presumably you are running a 32bit version of Java, and the system will be looking for a 32bit version of libXext.so.

>
> However, sometimes there's no error. Apparently it is looking for
> .../jdk1.6.0_14/jre/lib/i386/libawt.so
> and works fine.

Is this running the exact same code? It's strange if the same code requires different libraries. It's possible if execution paths are not the same, and so have different dependencies on which libraries are required at run time.

The library jdk1.6.0_14/jre/lib/i386/libawt.so has no dependency on libXext.so.6.

>
> Is there some order of looking up .so files, which can change due to some unknown factors?

The JVM, which runs the Java code, is just an application like any other Linux application.
Loading of dynamic shared objects (DSOs) is managed by the runtime linker ld.so, and a set of environment variables.
So the difference may be due to some other external factor which is changing the order, or path, which ld.so uses to search for DSOs.

>
> What is the command to list all .so files to be used by Java applications?

ldd is the program to list DSOs required by dynamically linked code. However, it can't list secondary dependencies, i.e DSOs loaded in response to requests made by executing code. i.e. the JVM runs some code which dynamically links to an external DSO via JNI. There isn't anything which can do this because it's truly dynamic. Until the running code actually makes a request to open the DSO there is nothing in the code to indicate the dependency.

>
> Was there an installation error? This java package was installed on 32-bit linux and used by 64-bit now.

The 32bit version of Java requires support of 32bit runtime libraries. If the system is now 64bit then some of those libraries may not have been installed.
Whether your flavour of Linux provides all the necessary 32bit runtime libraries is unknown. Some provide a comprehensive set of 32bit runtime support, and others do not. On my system I have a legacy 32bit install of Java 1.6. In that install I have the library re/lib/i386/xawt/libmawt.so. This is what ldd says about it:

$ ldd libmawt.so
         linux-gate.so.1 (0xf77c0000)
         libpthread.so.0 => /lib/libpthread.so.0 (0xf772e000)
         libm.so.6 => /lib/libm.so.6 (0xf76e8000)
         libawt.so => /usr/java/jdk1.6.0_29/jre/lib/i386/xawt/./../libawt.so (0xf7638000)
         libXext.so.6 => not found
         libX11.so.6 => not found
         libdl.so.2 => /lib/libdl.so.2 (0xf7632000)
         libXtst.so.6 => not found
         libXi.so.6 => not found
         libjava.so => /usr/java/jdk1.6.0_29/jre/lib/i386/xawt/./../libjava.so (0xf760d000)
         libjvm.so => not found
         libc.so.6 => /lib/libc.so.6 (0xf7460000)
         /lib/ld-linux.so.2 (0x565be000)
         libjvm.so => not found
         libjvm.so => not found
         libverify.so => /usr/java/jdk1.6.0_29/jre/lib/i386/xawt/./../libverify.so (0xf7454000)
         libnsl.so.1 => /lib/libnsl.so.1 (0xf743a000)
         libjvm.so => not found

So, on my system libXext.so.6 is also missing. (Ignore the missing libjvm.so, it's set at runtime based on whether the client or server JVM is executed).

I have 64bit X11 installed, and there is a version of libXext.so.6 in /usr/lib64, but no 32bit version in /usr/lib.

If I go searching for it I can find more information:.

$ rpm -q --whatprovides /usr/lib64/libXext.so
libXext-devel-1.3.3-3.1.x86_64

So I probably need to search for a 32bit version of this development package.
With sufficiently "lucky" searching I can find:

$ zypper search libXext6-32
Loading repository data...
Reading installed packages...

S | Name           | Summary                               | Type
--+----------------+---------------------------------------+--------
   | libXext6-32bit | Common extensions to the X11 protocol | package

which looks a likely candidate.

$ zypper info --provides libXext6-32bit
Loading repository data...
Reading installed packages...


Information for package libXext6-32bit:
---------------------------------------
Repository: Mirrorservice OSS
Name: libXext6-32bit
Version: 1.3.3-3.1
Arch: x86_64
Vendor: openSUSE
Installed: No
Status: not installed
Installed Size: 70.4 KiB
Summary: Common extensions to the X11 protocol
Description:
   The Xext library contains a handful of X11 extensions:
   - Double Buffer extension (DBE/Xdbe)
   - Display Power Management Signaling (DPMS) extension
   - X11 Nonrectangular Window Shape extension (Xshape)
   - The MIT Shared Memory extension (MIT-SHM/Xshm)
   - TOG-CUP (colormap) protocol extension (Xcup)
   - X Extended Visual Information extension (XEvi)
   - X11 Double-Buffering, Multi-Buffering, and Stereo extension (Xmbuf)
Provides:
   libXext.so.6
   libXext6-32bit == 1.3.3-3.1
   libXext6-32bit(x86-32) == 1.3.3-3.1
   xorg-x11-libXext-32bit == 7.6_1.3.3

and there it is.
I would also need to resolve the missing libXtst and libXi.

Hopefully there are similar tools on your Linux distro to help you locate the missing files.

You may be able to install an entire 32bit X11 system (including development libraries), but take care as this might destroy your 64bit one.
Be sure your distro supports this before attempting it.

You might also consider upgrading to a more recent, 64bit, version of Java.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web