I have tried it again , & the same exception keeps poping up , i think while reading through your post , that you have made a mod or a trick that have made the PI forces jme to use lwjgl repositories for lwjgl & not jme repos for lwjgl , I will appreciate that if you can illustrate !
It finally works , what i was actually missing is that ARMv8 Processor of RPI4B is a 64-bit processor that runs a 32-bit system(ARMv7l) for performance purposes , so implementing these in Raspibian context is wrong :
is essential , the others are actually bounded to jme-lwjgl3 so the implementation of the natives linux armv32 actually solves the exception of UnsatisfiedLinkError caused by liblwjgl.so for armv32 not found , this Exception :
[LWJGL] Failed to load a library. Possible solutions:
a) Add the directory that contains the shared library to -Djava.library.path or -Dorg.lwjgl.librarypath.
b) Add the JAR that contains the shared library to the classpath.
[LWJGL] Enable debug mode with -Dorg.lwjgl.util.Debug=true for better diagnostics.
[LWJGL] Enable the SharedLibraryLoader debug mode with -Dorg.lwjgl.util.DebugLoader=true for better diagnostics.
Jan 02, 2021 3:59:27 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[main,5,main]
java.lang.UnsatisfiedLinkError: Failed to locate library: liblwjgl.so
at org.lwjgl.system.Library.loadSystem(Library.java:162)
at org.lwjgl.system.Library.loadSystem(Library.java:62)
at org.lwjgl.system.Library.<clinit>(Library.java:50)
at org.lwjgl.system.MemoryUtil.<clinit>(MemoryUtil.java:97)
at org.lwjgl.system.Pointer$Default.<clinit>(Pointer.java:67)
at org.lwjgl.system.Callback.<clinit>(Callback.java:41)
at com.jme3.system.lwjgl.LwjglWindow.createContext(LwjglWindow.java:182)
at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:494)
at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:625)
at com.jme3.system.lwjgl.LwjglWindow.create(LwjglWindow.java:466)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:463)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:424)
at com.jme3.app.SimpleApplication.start(SimpleApplication.java:127)
at JmETest.main(JmETest.java:11)
Have you got the physics working dude ? because hereâs a new problem
bullet , bullet-native & Minie all gives me the same Exception , cannot locate the .so object file ,
Exception in thread "main" java.lang.UnsatisfiedLinkError: The required native library 'bulletjme' was not found in the classpath via 'native/linux/arm32/libbulletjme.so'. Error message: no bulletjme in 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]
at com.jme3.system.NativeLibraryLoader.loadNativeLibrary(NativeLibraryLoader.java:598)
at com.jme3.system.JmeDesktopSystem.initialize(JmeDesktopSystem.java:348)
at com.jme3.system.JmeDesktopSystem.newContext(JmeDesktopSystem.java:271)
at com.jme3.system.JmeSystem.newContext(JmeSystem.java:159)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:461)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:424)
at com.jme3.app.SimpleApplication.start(SimpleApplication.java:127)
at JmETest.main(JmETest.java:11)
i am currently searching lwjgl whether they have ports for armv32 or not !
EDIT : seems bullet physics is not operable on RPIs Raspibian system unless itâs supported by JmonkeyEngine, but we still have an option to use Lineage OS & switch the usage to android system , but notice , it would be hard to implement an interface for keyboard & mouse , it wonot work with the same behavior on the regular desktop
I am not using physics for my game yet, so havenât tried it. But like you said, this is now a JME issue. They need to support ARM in their desktop library, not only android library. Until that change is made in JME, Iâm afraid support is limited. The rest worked thanks to LWJGL supporting ARM and gradle being able to download those. If you are able to trick gradle into loading the ARM binaries used in Android, it might work. At this point, I would just request for ARM support to be added to JME natively. Specially Open GL ES, to see if we could get some performance gain.
And, from a quick look, I think @Pavl_G could probably get a working build by adding some gcc flags to the LinuxArm or LinuxArmHF builds of jme-bullet-native/build.gradle round about here:
(Iâd try it myself, but I donât have the compatible hardware to test it on.)
Also, make sure that JME has indeed built itâs normal LinuxARM binary, hate to have you mess about with Compiler settings and find that the normal build would have been fine If it had been BUILT.
I read through this build Gradle , found that arm32 is already supported , but I donot know why Gradle cannot locate libbulletjme.so under the /arm32 dir , plus I have never worked with native libraries before , so I would search around if I could do something
Notice : that this same exception happened with liblwjgl.so under the same dir , so itâs consistent & our fix for that was using LwJGL native implementation for arm32 , either something is wrong with jme or itâs Raspibian that causes the hit , I need to search more
Luckily, you can do most of the detective work through the gradle interface. Native libraries will only build if you have the correct Native compiler support available. This means a C/C++ compiler setup.
Try forcing just that particular library with .gradlew bulletjmeLinuxArmSharedLibrary and see what error message you get. If it tells you Could not find C++ compiler 'arm-linux-gnueabi-g++-8' or similar, you just need to install the correct compiler from your package manager.
If it builds, but wonât load on the Pi4, Then we need to look at specific architecture/arm version compatibility. Letâs not worry about that if we donât need to.
My guess is that the JME desktop library will only link to windows, mac and linux for pentium processors. that is why we had to manually add the binaries for ARM. the same must be happening for the bullet library, it is linking to the windows, mac and linux for pentium processors. Even if the ARM binary exists, there is nothing downloading it as a dependency.
Correct me if Iâm wrong , but I think others(jbullet,bullet-native) exhibit the same behavior as Minie does , since they are from the same origin , so the native build for Arm32 should be similar , but letâs focus first on Minie to make something work , when the first build for Arm32 is out there , please ping me here to start testing
I did more research. Native code compiled for âarmelâ should run on âarmhfâ hardware as well (albeit slowly). And since JME has no way to distinguish the 2, itâs safer to compile for âarmelâ. So thatâs what Iâll do.
I donot know whatâs âarmelâ but there is Profile Architecture missing , I donot know where I can find these on my PI4 but I will do some search if you will use this info.
Hi @sgold , i have made some search & found out that , there are architecture profiles for each arm processor architecture , so if we have Cortex-A72 model then its armv8-A or armv7l RaspiBian system 32-bit which is a 64bit hardware that supports 32-bit systems for performance purposes w/ encoding AArch64/A64 using 32-bit instructions :
pi@raspberrypi:~ $ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 108.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 1
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 108.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 2
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 108.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 3
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 108.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
Hardware : BCM2711
Revision : b03111
Serial : 10000000a459511c
Model : Raspberry Pi 4 Model B Rev 1.1
and to be sure of that i have searched through raspibian binaries in /usr/lib/ :
arm-linux-gnueabihf gnu is the gnu public support of linux UIs & builds , eabi is for compilation on bare-metal arm cores , hf is the hard floating point support âŚ
EDIT : this folder contains the jni folder which has the .so binaries for java .
So, now we are sure about what we are dealing w/ : basically : Cortex-A72(Hardware metal device) =armv7l(Software interface through Raspibian) = armv8-A(Hardware Product model name)=armhf(binaries for the system) which uses 32-bit instructions set & armel isnot an arm architecture as i understood from those topics , its only a software compilation of the compiler , i am not sure about armel.
