Prev: CUPS Child exited with status 1
Next: aspell clean [strict] file.txt
From: Quasar on 8 Mar 2007 12:09
Hi there,

Before posting my problem I've checked the internet for possible
solutions.

Said that, I'm trying to run a java application and I got the
following error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/
RaidMan/jre/lib/i386/libawt.so: libXp.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(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.action.LoadLibraryAction.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(Unknown Source)
at sun.awt.DebugHelper.<clinit>(Unknown Source)
at java.awt.Component.<clinit>(Unknown Source)

The OS is CentOs 4.4 and this is the uname -a output:
Linux source 2.6.9-42.0.8.ELsmp #1 SMP Tue Jan 30 12:18:01 EST 2007
x86_64 x86_64 x86_64 GNU/Linux

As suggested in http://docs.codehaus.org/display/ninja/Installing+JDK+1.4.2+on+FC4
I've installed the "xorg-deprecated" package and the file libXp.so.6
does exist in dir "/usr/X11R6/lib64"

If I run " ldd /usr/RaidMan/jre/lib/i386/libawt.so" I get:
linux-gate.so.1 => (0xffffe000)
libmlib_image.so => not found
libjvm.so => not found
libXp.so.6 => not found
libXt.so.6 => not found
libXext.so.6 => not found
libXtst.so.6 => not found
libX11.so.6 => not found
libm.so.6 => /lib/tls/libm.so.6 (0xf7cfe000)
libdl.so.2 => /lib/libdl.so.2 (0xf7cfa000)
libjava.so => not found
libc.so.6 => /lib/tls/libc.so.6 (0xf7bce000)
/lib/ld-linux.so.2 (0x56555000)

This clearly shows that the libawt.so cannot link the libXp.so
library. I tried to modify my LD_LIBRARY_PATH=/usr/X11R6/lib64 but
that didn't help. My ld.so.conf anyway already contained the
directory /usr/X11R6/lib64.

I hope I was good enough to explain you my problem and I'd be grateful
if someone could shed some light on this.

Thanks in advance.

Quasar

From: Dances With Crows on 8 Mar 2007 12:45
Quasar staggered into the Black Sun and said:
> Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/
> RaidMan/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object
> file: No such file or directory

Yep, a library's missing. The path given also seems like a very strange
one for putting a JRE in.

> The OS is CentOs 4.4 and uname -a : Linux source 2.6.9-42.0.8.ELsmp #1
> SMP Tue Jan 30 12:18:01 EST 2007 x86_64 GNU/Linux

There can be problems with running 32-bit apps on amd64 machines. Lots
of stuff works fine, but there are also things that don't work at all,
like epsxe. I've tried to avoid Java as much as possible, so I don't
know specifics of how Java may or may not suck on amd64.

> I've installed the xorg-deprecated package and the file libXp.so.6
> does exist in /usr/X11R6/lib64. ldd
> /usr/RaidMan/jre/lib/i386/libawt.so [gives]:
> libmlib_image.so => not found libjvm.so => not found
> libXp.so.6 => not found libXt.so.6 => not found
> libXext.so.6 => not found libXtst.so.6 => not found
> libX11.so.6 => not found libjava.so => not found

Lots of stuff besides libXp isn't there. Which version of which JRE is
this? Was it installed via Redhat's excuse for a package management
system?

> I tried to modify my LD_LIBRARY_PATH

Probably the wrong way to do it.

> My ld.so.conf already contained the directory /usr/X11R6/lib64.

Did you run ldconfig after installing the new libs? RPM is supposed to
do this, but if you installed things without a package management
system, this step might've been skipped. Anyway, make sure all the
other libs that libawt.so links to are on the system and in dirs that
appear in ld.so.conf. If they aren't, time to install them and/or
modify ld.so.conf such that they're there.

--
There was also a recipe for pina colada, in Portuguese, which the
Google translator told me needed "hand grenades". Someone had put in
a colloquial translation of 'pineapple'... --Chris Croughton
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
From: Quasar on 9 Mar 2007 07:18
On 8 Mar, 18:45, Dances With Crows <danSPANceswithTRAPcr...(a)gmail.com>
wrote:

> There can be problems with running 32-bit apps on amd64 machines. Lots
> of stuff works fine, but there are also things that don't work at all,
> like epsxe. I've tried to avoid Java as much as possible, so I don't
> know specifics of how Java may or may not suck on amd64.

You are right. I simply installed 64-bits Sun JRE and the problem was
gone.

Thanks a lot!

Quasar

From: Dances With Crows on 9 Mar 2007 12:22
Quasar staggered into the Black Sun and said:
> Dances With Crows wrote:
>> There can be problems with running 32-bit apps on amd64 machines.
>> Lots of stuff works fine, but there are also things that don't work
>> at all, like epsxe. I've tried to avoid Java as much as possible, so
>> I don't know specifics of how Java may or may not suck on amd64.
> You are right. I simply installed [the] 64-bit Sun JRE and the problem
> was gone.

Interesting. That makes me think your original problem may have been
due to incomplete and/or broken x86-32 emulation. In Gentoo, at least,
all the compatibility libs for x86-32 are installed by default when you
do an amd64 install. I've heard that other distros are ... less good
about that in some cases. Oh well, good to know that it's all working
now.

--
Sturgeon's Law: 90% of everything is crud.
MG's Extension: The other 10% is included in "everything," and it's
recursive.
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
 | 
Pages: 1
Prev: CUPS Child exited with status 1
Next: aspell clean [strict] file.txt