UnsatisfiedLinkError in Eclipse

pas54

I wrote a sketch on Eclipse that makes use of the GPIO pins on a raspberry pi. When I test the sketch on my laptop, it works fine. It gives me a message saying that since the program is on a laptop, it will simulate the GPIO activity. I expected that, and it's not my problem.

The problem came when I exported the program out as a runnable jar file, and loaded it onto my raspberry pi 0. When I run the program, it runs for a split second before freezing up, and on my terminal I get the following error

java.lang.UnsatisfiedLinkError: no processing-io in java.library.path

I don't understand. This can't be the case, as I'm positive I included the processing-io library in the program build. Can anybody explain to me why this is happening, and/or what I can do to address this issue and get the program running?

gohai

@pas54 It probably isn't finding the libprocessing-io.so file, which needs to be inside the library path to work. Processing proper makes sure that library/linux-armv6hf is part of this path, but no idea about Eclipse (not a configuration we can support).

pas54

@gohai I've accidentally taken a step backwards. The application was running as a jar file when I'd export it to my laptop. Now it isn't even working on my laptop. I get the following error when I try to run the application from command line :

java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\fillu\natives\windows-amd64\\nativewindow_awt.dl

The program still runs from inside eclipse just fine. What in god's name is going on here??? It seems like no matter what I do, I can't get the program exported as a properly working jar file. If it works on my laptop, it doesn't work on the pi. If it works from eclipse, it doesn't work on my laptop. I thought Java was "Write once, run anywhere". PLEASE HELP!!! I'm also including a screen shot of the jars and libraries in my project.

pas54

gohai

@pas54 Please try within the Processing IDE.

pas54

@gohai The program launches just fine from both the eclipse and processing ide. If I export it from eclipse, it doesn't work on my laptop or the raspberry pi. If I export it from processing ide, it works on my laptop, but not on the raspberry pi. Is there a way we could do a live chat? I'm sure these problems have an easy fix, but it seems like talking through the message boards will be very slow.

gohai

@pas54 Please upload your sketch to pastebin or similar, and also include the error you're receiving when you're attempting to execute the sketch exported from Processing (!) on the Raspberry Pi.

pas54

@gohai do you want the code or the file?

gohai

@pas54 All of the code you're compiling in the PDE, as well as the specific error message you're getting when running said code on the Raspberry Pi. Feel free to send privately if you don't want to share your code publicly.

pas54

@gohai UPDATE I sent the code to you privately

gohai

@pas54 I can't seem to get the code you sent to compile inside the PDE - are you sure it does?

pas54

lol. Sorry. I included the code to make it work in eclipse, like the p-applet stuff. Let me send you the right code

gohai

@pas54 If you're no longer seeing the "Unsatisfied Link Error" when exporting from Processing, but you say that instead the sketch appears to "hang", then I'd recommend the proven strategy of starting by testing the nucleus of the sketch (e.g. without minim), and then over-time pulling in more and more of your existing code. This will point you to where the issue is.

If you don't want to run the PDE on the Pi, but manually exporting the sketch is too daunting: there is an UploadToPi tool for Processing (in the Contribution Manager), which will export the sketch for Pi, upload the files via SFTP and run them on the device. You even get the output back onto Processing's console area.

pas54

@gohai The reason I'm trying to do it from eclipse is because I don't actually want the processing window to appear, which from what I've read can only be done outside of the PDE environment. The visuals in the sketch are just for me, to verify what's going on in the program as it happens. The final version of the program on the pi shouldn't be visible to the user. It's really the sound analysis features of processing/minim that I'm aiming to use. Also, the loop rate of the draw method is perfect for what i'm doing. I don't want to move towards using a loop rate different than that of processing.

pas54

@gohai , if it's at all possible, I would really appreciate it if you could take me through the steps of configuring an eclipse project to run a processing sketch. None of the tutorials are working for me. I keep getting this error

java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\fillu\natives\windows-amd64\\nativewindow_awt.dll
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.load0(Unknown Source)
        at java.lang.System.load(Unknown Source)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:624)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:63)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:106)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:487)
        at jogamp.nativewindow.NWJNILibLoader.access$000(NWJNILibLoader.java:39)
        at jogamp.nativewindow.NWJNILibLoader$1.run(NWJNILibLoader.java:49)
        at jogamp.nativewindow.NWJNILibLoader$1.run(NWJNILibLoader.java:41)
        at java.security.AccessController.doPrivileged(Native Method)
        at jogamp.nativewindow.NWJNILibLoader.loadNativeWindow(NWJNILibLoader.java:41)
        at jogamp.nativewindow.jawt.JAWTUtil.<clinit>(JAWTUtil.java:336)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at com.jogamp.nativewindow.NativeWindowFactory$3.run(NativeWindowFactory.java:346)
        at com.jogamp.nativewindow.NativeWindowFactory$3.run(NativeWindowFactory.java:342)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.nativewindow.NativeWindowFactory.initSingleton(NativeWindowFactory.java:342)
        at com.jogamp.newt.NewtFactory$1.run(NewtFactory.java:68)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.newt.NewtFactory.<clinit>(NewtFactory.java:65)
        at processing.opengl.PSurfaceJOGL.initIcons(PSurfaceJOGL.java:498)
        at processing.opengl.PSurfaceJOGL.initFrame(PSurfaceJOGL.java:134)
        at processing.core.PApplet.initSurface(PApplet.java:10691)
        at processing.core.PApplet.runSketch(PApplet.java:10578)
        at processing.core.PApplet.main(PApplet.java:10318)
        at processing.core.PApplet.main(PApplet.java:10300)
        at Main.main(Main.java:485)
        ... 5 more

gohai

@pas54 Perhaps someone else can, but I can't. Good luck with that.

kfrajer

@pas54 An akternative solution is to make the Processing window translucent/transparent: Check if the following trick works for you: https://forum.processing.org/two/discussion/20499/moving-a-translucent-window-around-the-screen/p1

I know this is not the proper way to do things but at least it could be an alternative if you want to completely hide the window. You could even have processing to read a configuration file in your pde's setup() function. In this config file you have a single value, either 0 or 1. This value could be use to set the opacity of the window when the program starts. In testing mode, you could set the value to 1 so to get access to the window, otherwise you set it to zero.

Kf

pas54

@kfrajer that's a great suggestion. Thank you. @gohai thank you as well. To all, I think I figured out that the pi 0 just doesn't have the juice for my application. It's running an FFT at 44100/sec, plus the processing visuals. I'm going to try to cut out processing from the equation, since I don't actually need the visuals at this point. Just the FFT algorithm and access to the gpio pins is all I really need. So, in summary, the answer to this question is : Raspberry Pi Zero is too puny for my program!! I verified this by exporting the same code to a Raspberry Pi 3, and it works just fine.

kfrajer

I think what matters for this calculation is the buffer size and not so much the sampling rate. I will guess the buffer size of your app could be 1024 bins. Maybe you could lower it to 256 and see if this helps. I would suggest using the default sketch size of 100x100 is the lowest you can go but should reduce overhead. Unfortunately, these changes might not make any major improvement and you are truly limited by your platform.

@jeremydouglass Do you know anything about running processing in headless mode? I believe I saw a post talking about his mode, running processing in a server where there was no graphical support. I might be using the wrong terminology.... or I might be wrong and I could have seen it in another forum.

*****EDIT: More about headless mode:
https://forum.processing.org/two/search?Search=xvfb
https://forum.processing.org/two/search?Search=headless

Kf

pas54

@kfrajer I actually learned all about headless mode. Originally, I was trying to run this program that way, but it gave me fits, and ultimately led to my conclusion in the previous post. That is an interesting thought, however. Are you suggesting that if I can get it running on a raspbian lite OS, and run the application on there, that it wouldn't have to do the graphical processing?

As far as your first suggestion, that is another great idea. I will see if that helps. If not I'll just take processing out of the equation, which seems doable as well.