Can't load IA 32-bit .so on a IA 32-bit platform

Hi All,

java.lang.UnsatisfiedLinkError: /root/workspace/skype_api/release/libJSA.so: Can't load IA 32-bit .so on a IA 32-bit platform

Has anyone any idea what this message is supposed to mean? This occurs when trying to load a JNI Library. Do I need to compile it with some special flags or something?

I have been able to reproduce this on two completely different PC's.

Thanks,

Serge

[423 byte] By [s_sozonoffa] at [2007-10-3 11:40:36]
# 1

> Hi All,

>

> java.lang.UnsatisfiedLinkError:

> /root/workspace/skype_api/release/libJSA.so: Can't

> load IA 32-bit .so on a IA 32-bit platform

>

> Has anyone any idea what this message is supposed to

> mean? This occurs when trying to load a JNI Library.

> Do I need to compile it with some special flags or

> something?

>

> I have been able to reproduce this on two completely

> different PC's.

>

> Thanks,

> Serge

Funny I get the same thing on Solaris

Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/anithian/lib/libGraphics.so: Can't load Sparc 32-bit .so on a Sparc 32-bit platform

I haven't found anything online about it... please post suggestions.

anithiana at 2007-7-15 14:09:51 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 2

Using the JDK 5.0 Update 10 on SUSE Linux Enterprise Desktop 10, I just ran into a similar issue. It's definitely a cryptic error message. This is the output I saw:

Exception in thread "Thread-1" java.lang.UnsatisfiedLinkError: /home/ktasinga/development/aperi/AperiDebug/lib/linux-ix86/libDataServer.so: Can't load IA 32-bit .so on a IA 32-bit platform

at java.lang.ClassLoader$NativeLibrary.load(Native Method)

at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)

at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)

at java.lang.Runtime.loadLibrary0(Runtime.java:822)

at java.lang.System.loadLibrary(System.java:993)

...

Not sure what was going on, I decided to try running my code with an earlier version of JDK 5.0. I, rather randomly, chose to run with JDK 5.0 Update 7. Result? I was greeted with the following, different, output:

Exception in thread "Thread-1" java.lang.UnsatisfiedLinkError: /home/ktasinga/development/aperi/AperiDebug/lib/linux-ix86/libDataServer.so: /home/ktasinga/development/aperi/AperiDebug/lib/linux-ix86/libDataServer.so: undefined symbol: adminGIDField

at java.lang.ClassLoader$NativeLibrary.load(Native Method)

at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)

at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)

at java.lang.Runtime.loadLibrary0(Runtime.java:822)

at java.lang.System.loadLibrary(System.java:992)

...

Weird, huh? Anyway, I went back and looked through my source tree and noticed a mistake in one of my Makefiles. After correcting the mistake, my code ran fine in not only JDK 5.0 Update 7, but also JDK 5.0 Update 10.

You didn't state what level of the JDK you were using. However, if you happen to be using JDK 5.0 Update 10, you might try going back to an earlier release (http://java.sun.com/products/archive/), to see if you can get a better error message. In the end, you may actually be facing some sort of native compilation issue.

I hope that helps.

Regards,

Khan

ktasingaa at 2007-7-15 14:09:51 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 3
I ran into this problem too, thanks for the advice.
Jeremy.Fa at 2007-7-15 14:09:51 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 4

The bug fix 6374419 which went into update 10 and mustang changed the message to be more helpful in the case where you were trying to use a library which wasn't compatible with your platform. The problem is that it suppresses the helpful error message in the case where that's not your problem. I've filed 6515362 for this issue. The workaround is to go to an earlier JDK release if you see this error message. The bug was recently filed so it may not show up in the bug database yet.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6374419

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6515362

On Solaris you may also be able to track it down using the LD_DEBUG environment variable to see debug output from the runtime linker. Setting LD_DEBUG to "help" will give you information on using it.

tom

neverevera at 2007-7-15 14:09:51 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 5

Found this via Google and wanted to add my experiences.

I'm on Solaris and I use Java 1.5. Update 10. My app is using native libraries.

I had the same problem with the cryptic message

Exception in thread "main" java.lang.UnsatisfiedLinkError: mylib.so: Can't load Sparc 32-bit .so on a Sparc 32-bit platform

Downgrading to a previous version and upgrading to Java 6 allowed me to see the true cause of the problem.

In my case I thought I was clever by setting the java.library.path property, i.e. I started java like this:

java -Djava.library.path=/xxx....

as an alternative to setting LD_LIBRARY_PATH. That worked fine until I had a native library that referenced another native library. Then the library being referenced could not be loaded.

Bottom line for me: Set the LD_LIBRARY_PATH, don't use the java.library.path property on the JVM.

lbruuna at 2007-7-15 14:09:51 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 6

I have the same error:

...

Can't load IA 32-bit .so on a IA 32-bit platform

...

on a Pentium4 running Fedora Core 3, using java build 1.5.0_10-b03

though I am using LD_LIBRARY_PATH and not -Djava.library.path.

But one native library referencing another native library is a good hint, gonna look into that.

thanks!

mzillicha at 2007-7-15 14:09:51 > top of Java-index,Java HotSpot Virtual Machine,Specifications...