Java Native/Shared Library (.so) laden macht Probleme

[Fohnbit]

Hallo!

Ich habe unter Windows eine kleine Application geschrieben, die auf einem Linux ausgeführt wird.
Die Application benötigt aber eine Java Native/Shared Library (.so) Names demo.so.

Ich habe auf dem Linux System:
export LD_LIBRARY_PATH="/home/debian/java"
ausgeführt.

Auf dem Windowsrechner habe ich die Jar erzeugt und in das obige Verzeichnis kopiert.
Führe ich nun das programm auf der Linux Console aus:
java -jar -Djava.library.path=".:/home/debian/java" demo.jar

erhalte ich:
Native code library failed to load.
java.lang.UnsatisfiedLinkError: /home/debian/java/demo.so: /home/debian/java/demo.so: cannot open shared object file: No such file or directory

Jedoch die Datei existiert und habe sogar chmod 7777 gegeben.

Der Javacode:

package soDemo;

public class SoDemo {

	static {
	    try {
	    	System.load("/home/debian/java/demo.so");
	    	System.loadLibrary("demo");
	    } catch (UnsatisfiedLinkError e) {
	      System.err.println("Native code library failed to load.\n" + e);
	      System.exit(1);
	    }
	  }
	
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		SoDemo soDemo = new SoDemo();
	
	}

}

 

[mtheiss]

Hallo,

führe mal
ldd /home/debian/java/demo.so aus und schaue, ob alle verlinkten Libraries gefunden werden können.

Andere Möglichkeit wäre noch, dass du versuchst unter einer 32bit VM eine 64bit Shared Library zu laden (oder andersrum).

Gruss
Martin

 

[Fohnbit]

Hallo!

Der Befehl führt zu:
not a dynamic executable

Der Befehl "file ./demo.so" führt zu:
./libpoll4j.so: setuid setgid sticky ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped

Java Version:
java version "1.8.0_06"
Java(TM) SE Runtime Environment (build 1.8.0_06-b23)
Java HotSpot(TM) Client VM (build 25.6-b23, mixed mode)

System:
Linux beaglebone 3.8.13-bone67 #1 SMP Wed Sep 24 21:30:03 UTC 2014 armv7l GNU/Linux

Siehst du hier irgendwo einen Fehler?

Danke!

 

[arilou]

Hab' zwar nur wenig Ahnung von JNI, aber zieh' erst mal die beiden Zeilen

System.load("/home/debian/java/demo.so");
System.loadLibrary("demo");

in jeweils eigene try-catch-Blöcke, um zu sehen, an welcher genau es liegt.
Außerdem würde ich mal probieren, was passiert, wenn du aus der ersten Zeile die Pfadangabe weglässt, denn die kennt die JVM doch schon?

System.load("demo.so");

Vielleicht hilft's auch, die Datei umzubenennen in libpoll4j.so , was anscheinend ihr "interner Name" ist?
Oder du musst sie mit diesem Namen in der zweiten Zeile anfordern?

System.loadLibrary("libpoll4j"); // oder "libpoll4j.so"

Keine Ahnung, ob irgend etwas davon hilft.