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

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

Re: Looking up .so file failure

Show all headers | View raw

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.

Back to comp.lang.java.programmer | Previous | Next — Previous 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