/home/pi/IdeaProjects/RPI4B/libbulletjme.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=a65fb57f30b28696d3242c9173698b122d2ba7db, not stripped
its 32bit shared object , so out of curiosity , i know that .so files are object files that have machine code(binary code) generated by the jvm during runtime interpreted to hexcode, but what’s the difference between a shared & executable object ?
i know that .so files are object files that have machine code(binary code) generated by the jvm during runtime interpreted to hexcode, but what’s the difference between a shared & executable object ?
The code in an .so file is generated by a compiler at build time, not by the JVM at run time.
Generally, the code in an .so file is executed directly by the CPU, not interpreted. (That’s why it’s platform-specific.)
A shared library contains native code that can be shared between multiple Linux processes, even if those processes are running different applications. I think library sharing was developed to conserve physical memory.
For JMonkeyEngine, the key benefit of a shared library is dynamic linkage: our Java apps can invoke its native methods even though they’re not statically linked into the Java Virtual Machine.
As for the UnsatisfiedLinkError, I need time to decide how to debug this remotely. I’m open to suggestions…
The javadoc for System.load() says that “the filename argument is mapped to a native library image in an implementation-dependent manner”. In other words, the JVM might not actually be looking in “/home/pi/IdeaProjects/RPI4B” for the file.
Looking back at the “java -XshowSettings:all” output, I see that there’s a “java.library.path” property. Please copy the “libbulletjme.so” file to one of those directories, set the owner and permissions appropriately, and retest.
pi@raspberrypi:~ $ sudo cp /home/pi/IdeaProjects/RPI4B/libbulletjme.so /usr/java/packages/lib /usr/lib/arm-linux-gnueabihf/jni /lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf /usr/lib/jni /lib /usr/lib
cp: cannot stat '/usr/java/packages/lib': No such file or directory
cp: -r not specified; omitting directory '/usr/lib/arm-linux-gnueabihf/jni'
cp: -r not specified; omitting directory '/lib/arm-linux-gnueabihf'
cp: -r not specified; omitting directory '/usr/lib/arm-linux-gnueabihf'
cp: cannot stat '/usr/lib/jni': No such file or directory
cp: -r not specified; omitting directory '/lib'
I have copied the libbulletjme.so to /usr/lib/arm-linux-gnueabihf/jni & the operation is successful but it didnot work too giving the same Error
EDIT :
Someone says here that you could activate RPi4B 64bit kernal mode through :
The 32-bit kernel image for the RPi 4 is named kernel7l.img, the 64-bit kernel image kernel8.img, but 64-bit mode is not activated automatically like on the RPi 3. A config.txt file with this entry is needed:
Code: Select all
arm_64bit=1
It’s not activated by default
I donot know if this can help or not
It does say that this should be an absolute path/file name. (Which it is, given the above discussion). The JME system is generating the actual path, so moving the library around seems… unlikely to do anything.
That’s analogous to classpath, but for native libraries. The fact that the error is giving a full path to the .so indicates that JME platform is setting this automatically.
The Javadoc for System.load() also implies that there may be some virtual paths for libraries that are statically linked into the JVM.
That would be something to do on your end, setting your Pi to run 64 bit. You would then need to install 64 bit java, (and possibly change some parts of your OS) and JME would try to use the ARM64 version of libbulletjme.so
Javadoc for System.load() and the UnsatisfiedLinkError also indicate that this error can mean that the library is there, but that the native methods are not compatible.
My current suspicion is an incompatibility with the compiler options. If you review post 60, I don’t think that the processor in question has hf (Note the references to VFP)
readelf -A /proc/self/exe | grep Tag_ABI_VFP_args - If no response, the OS/chip is set to use hf, if response is Tag_ABI_VFP_args: VFP registers, it’s using Vector Floating Point. Source
so , i guess its an armhf now , & due to the in-availability of jvm backward compatibility we still have incompatible binaries , i think i would like to try enabling the 64-bit & do these kinda of java investigations again , may be we can get something , @sgold , @sailsman63 if i am getting something or understanding something wrong , please inform me !
Also: I seem to have been wrong about the hf stuff - vfp is the hardware floating point support.
I still think that it’s probably a mismatch between what the processor supports, and the options that @sgold’s compiler defaults to. If he runs arm-linux-gnueabihf-gcc -E -v we’ll get a look at some of the default options (a lot of supporting libraries, but also flags regarding which architecture/features to target)
I also think that 64 bits is not the way to go. Specially since most users won’t have that enabled and if you want people to try out your game in the pi, then they won’t be able to unless they enable the 64 bits.
That’s not how the Linux “cp” command works. “cp” only allows you to specify a single destination directory. Select a single directory from the java.library.path (preferably “/usr/java/packages/lib”) and copy the native library there.
Well, a 64-bit kernel would allow you to run a 64-bit JVM, which would give you a Linux_ARM64 platform. Minie already includes a native library for Linux_ARM64, and it’s well-tested, so it would probably work on your hardware.
My goal at the moment is to get Minie working on Linux_ARM32. If you don’t mind, I’d like to continue pursuing that goal.
I specifically tried not to compile for “hf”. That’s why I installed the g++-5-arm-linux-gnueabi cross-compiler package instead of g++-5-arm-linux-gnueabihf. The exact compiler version used was:
My goal is to build libraries for different PIs , & kiosk system apps as user end system only on my device but I will consider this , thanks for the alert
EDIT: I think , you are totally right , I would need something that’s compatible also with pi zero or all pi versions , because when I have a final kiosk project as an SD card with a system & my app , I will also need it to be compatible with any pi & not all PIs have 64-bit support on the metal bare cortex
I had hoped that non-hf binaries would run on gnueabihf systems, specifically yours.
If that’s not the case, then JMonkeyEngine needs to distinguish between hf and non-hf platforms—which it doesn’t, yet.
To test this hypothesis, I’ll build gnueabihf native libraries. While I’m doing that, I’d like you to please run the following console app and report the output:
import com.jme3.system.NativeLibraryLoader;
import java.io.File;
public class Main {
public static void main(String[] arguments) {
System.out.println("os.arch = " + System.getProperty("os.arch"));
System.out.println("os.name = " + System.getProperty("os.name"));
System.out.println("user.dir = " + System.getProperty("user.dir"));
System.out.println();
String libraryPath = System.getProperty("java.library.path");
System.out.println("original java.library.path = " + libraryPath);
System.setProperty("java.library.path", ".:" + libraryPath);
libraryPath = System.getProperty("java.library.path");
System.out.println("modified java.library.path = " + libraryPath);
System.out.println();
String[] directoryNames = libraryPath.split(":");
for (String directoryName : directoryNames) {
testDirectory(directoryName);
}
System.out.println();
File file = new File("./libbulletjme.so");
if (file.exists()) {
boolean success = file.delete();
if (success) {
System.out.println("Deleted a stale image.");
System.out.println();
}
}
try {
NativeLibraryLoader.loadNativeLibrary("bulletjme", true);
System.out.println("Success!");
} catch (Throwable throwable) {
System.out.println("Failed to load the native library.");
testDirectory(".");
throw new RuntimeException(throwable);
}
}
static void testDirectory(String directoryName) {
File file = new File(directoryName, "libbulletjme.so");
String path = file.getAbsolutePath();
if (file.exists()) {
System.out.println(path + " exists:");
if (file.isFile()) {
long length = file.length();
System.out.println(" " + path + " is a normal file of " + length + " bytes.");
}
if (file.canRead()) {
System.out.println(" " + path + " is readable.");
}
if (file.canExecute()) {
System.out.println(" " + path + " is executable.");
}
} else {
System.out.println(path + " doesn't exist.");
}
}
}
os.arch = arm
os.name = Linux
user.dir = /home/pi/IdeaProjects/RPI4B
original java.library.path = /usr/java/packages/lib:/usr/lib/arm-linux-gnueabihf/jni:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib
modified java.library.path = .:/usr/java/packages/lib:/usr/lib/arm-linux-gnueabihf/jni:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib
/home/pi/IdeaProjects/RPI4B/./libbulletjme.so exists:
/home/pi/IdeaProjects/RPI4B/./libbulletjme.so is a normal file of 3670564 bytes.
/home/pi/IdeaProjects/RPI4B/./libbulletjme.so is readable.
/usr/java/packages/lib/libbulletjme.so doesn't exist.
/usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so exists:
/usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so is a normal file of 3670564 bytes.
/usr/lib/arm-linux-gnueabihf/jni/libbulletjme.so is readable.
/lib/arm-linux-gnueabihf/libbulletjme.so doesn't exist.
/usr/lib/arm-linux-gnueabihf/libbulletjme.so doesn't exist.
/usr/lib/jni/libbulletjme.so doesn't exist.
/lib/libbulletjme.so exists:
/lib/libbulletjme.so is a normal file of 3670564 bytes.
/lib/libbulletjme.so is readable.
/usr/lib/libbulletjme.so exists:
/usr/lib/libbulletjme.so is a normal file of 3670564 bytes.
/usr/lib/libbulletjme.so is readable.
Deleted a stale image.
Failed to load the native library.
/home/pi/IdeaProjects/RPI4B/./libbulletjme.so exists:
Exception in thread "main" /home/pi/IdeaProjects/RPI4B/./libbulletjme.so is a normal file of 3670564 bytes.
java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: /home/pi/IdeaProjects/RPI4B/libbulletjme.so: /home/pi/IdeaProjects/RPI4B/libbulletjme.so: cannot open shared object file: No such file or directory
/home/pi/IdeaProjects/RPI4B/./libbulletjme.so is readable.
at JmETest.commandLineTest(JmETest.java:52)
at JmETest.main(JmETest.java:13)
Caused by: java.lang.UnsatisfiedLinkError: /home/pi/IdeaProjects/RPI4B/libbulletjme.so: /home/pi/IdeaProjects/RPI4B/libbulletjme.so: cannot open shared object file: No such file or directory
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1837)
at com.jme3.system.NativeLibraryLoader.loadNativeLibrary(NativeLibraryLoader.java:685)
at JmETest.commandLineTest(JmETest.java:46)
... 1 more