Problem loading shared-library

Hi,

I wrote a Java GUI using JNI to interface a C++-library. On my primary system -Gentoo 64-bit with an Athlon64 processor- everything works fine. Actually, it should run on a Solaris system. As the C++ library is supposed to run on a 64-bit system, I installed the Java 64-bit edition on the Solaris system (that hosts a Sparc V9 processor). Compiling the library with gcc on the latter system resulted in a shared library named libSimulatorLib.so. The file command on this library brings up the following output:

libSimulatorLib.so:ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, stripped

So far everything seemed okay, but after invoking the Java GUI I got the following exception, when the library is being loaded:

Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: /home/jan/workspace/bin/libSimulatorLib.so: Can't load Sparc v9 64-bit .so on a Sparc v9 64-bit platform

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 org.jan.LogicSimulator.KernelInterface.SimulatorKernel.<clinit>(SimulatorKernel.java:15)

at org.jan.LogicSimulator.Resources.ResourceManager.getSimulator(ResourceManager.java:153)

at org.jan.LogicSimulator.SimulatorPane.startSimulation(SimulatorPane.java:622)

at org.jan.LogicSimulator.SimulatorDialog$OKLsnr.actionPerformed(SimulatorDialog.java:107)

at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)

at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)

at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)

at javax.swing.DefaultButtonModel.setPressed(Unknown Source)

at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)

at java.awt.Component.processMouseEvent(Unknown Source)

at javax.swing.JComponent.processMouseEvent(Unknown Source)

at java.awt.Component.processEvent(Unknown Source)

at java.awt.Container.processEvent(Unknown Source)

at java.awt.Component.dispatchEventImpl(Unknown Source)

at java.awt.Container.dispatchEventImpl(Unknown Source)

at java.awt.Component.dispatchEvent(Unknown Source)

at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)

at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)

at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)

at java.awt.Container.dispatchEventImpl(Unknown Source)

at java.awt.Window.dispatchEventImpl(Unknown Source)

at java.awt.Component.dispatchEvent(Unknown Source)

at java.awt.EventQueue.dispatchEvent(Unknown Source)

at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)

at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

at java.awt.EventDispatchThread.run(Unknown Source)

I haven't found a similar message in the internet. Anyway, even this message means less than nothing to me, as it just mentions that the library is running on the system it is compiled for. Can anybody tell me what is going wrong?

Thanks,

Jan

[3483 byte] By [JanOrtnera] at [2007-11-26 15:29:24]
# 1

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-8 21:45:42 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 2
Can you guys give a simple test case? I can't reproduce.The only way to reproduce it is if a given .so file can be opened for reading by jvm but reading of first 52 bytes fails.Shall be fixed shortlyMessage was edited by: ivan.krylov
ivan.krylova at 2007-7-8 21:45:42 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 3

@neverever:

Sorry, for the late answer, was quite buisy these days.

The bug you are referring to, applies for loading a 32-bit library on a 64-bit system or vice versa, but I'm trying to load a 64-bit library on a 64-bit system (at least with the 64-bit jvm, as Solaris supports both 64-bit and 32-bit libraries, but this is definetly not the problem, as I get the error message "wrong elf class", when trying to load a 32-bit .so with the 64-bit jvm).

Installing Java6 and using the LD_DEBUG variable brings the solution for this problem a bit closer, as the error message gets a bit more detailed:

Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: /home/jan/workspace/bin/libSimulatorLib.so: ld.so.1: java: fatal: relocation error: R_SPARC_HI22: file /home/jan/workspace/bin/libSimulatorLib.so: symbol (unknown): value 0x3fffffffcab7ff does not fit

Actually I don't know what this is meaning too, but I think I may be able to find out, in contrast to the "don't use 64-bit library on 64-bit platform" error message above.

Thanks for your help,

Jan

@ivan.krylov

Sorry, but I can't give you a simple test case, as I don't know exactly what's going wrong. I think it is something specific to my Solaris system. As I said above everything is running fine on my Gentoo system.

Message was edited by:

JanOrtner

JanOrtnera at 2007-7-8 21:45:42 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 4
The bug with misleading message shall be fixed in update 2 of JDK 6 and update 12 of JDK 5.2JanOrtner: Once you started 32- or 64-bit java, you can only load .so libraries for the same architecture.
ivan.krylova at 2007-7-8 21:45:42 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 5
That is a weird error message. Do you have any hand written assembly in your library? http://developers.sun.com/solaris/articles/sparcv9abi.html talks about some problems with assembly on 64-bit that result in the same error message.tom
neverevera at 2007-7-8 21:45:42 > top of Java-index,Java HotSpot Virtual Machine,Specifications...