I have java code that needs to use the Vlcj library on a Raspberry Pi 3 B+ with Raspbian. But when starting up with the NativeDiscovery.discover(), i get a "no vlc library found" message. I have tried to use addSearchPath() on "/usr/bin/" with no success.
How can I solve my issue? Thanks
Your JVM needs to know where to find libvlc.so and the VLC plugins.
They are not in "/usr/bin".
There is more than one way to try and resolve this, the simplest perhaps is to use LD_LIBRARY_PATH.
Once you have found the directory containing libvlc.so, you can specify the LD_LIBRARY_PATH environment variable when you start your app.
On my Pi, libvlc.so is in /usr/lib/arm-linux-gnueabihf, so something like (the given jar files in the classpath are just examples):
LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf java -cp vlcj.jar:jna.jar:jna-platform.jar:your-app.jar
This might be enough to make it work, it might not. LibVlc might complain about not being able to find its plugins.
If so, find where the plugins are installed (there should be a directory named "plugins" under the directory where you found libvlc.so).
On my Pi these are in /usr/lib/arm-linux-gnueabihf/vlc/plugins.
Now you set the VLC_PLUGIN_PATH to point to that directory:
LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf VLC_PLUGIN_PATH=/usr/lib/arm-linux-gnueabihf/vlc/plugins java -cp vlcj.jar:jna.jar:jna-platform.jar:your-app.jar
You can set those environment variables in your profile or whatever instead of specifying on the command line if you want.
vlcj's native discovery mechanism generally tries to resolve all of this nastiness for you, but it doesn't (currently) know about Raspberry Pi so you have to do it yourself.
The next major version of vlcj (which will be 4.0.0) has an improved native discovery mechanism. I tested an early development version of this on my Pi and it just worked straight away without any of the above.
Related
Update: The problem was solved with the help of MathWorks. I've published the answer below.
I need to control a program (Zemax) from Matlab. Unfortunately, Zemax only supports DDE for such control, which Matlab does not support any more. It works, but stops working on 64 bit platform after a few (presumable 63) DDE calls.
I wonder if there are working solutions. I could probably program a DLL with correct DDE support and then use DDE in Matlab via this DLL. This is a major effort for me. A more suitable solution would be to use Java DDE methods. Following another post here, I've discovered the JDDE library. However I cannot make it work: Even if I am in the directory with the DLL and JAR files, executing
import pretty-tools.JDDE-2.0.3.*
works fine but calling
a = com.pretty_tools.dde.client.DDEClientConversation()
afterwards (as done here) results in
Undefined variable "com" or class "com.pretty_tools.dde.client.DDEClientConversation".
I have very limited writing privileges on my PC, so I have added the javaclasspath.txt file with the jar/dll location to the directory indicated by prefdir. The file looks like this:
C:\Users\xxxxxxxx\Documents\matlab toolbox\jdde\pretty-tools-JDDE-2.0.3.jar
Calling javaclasspath shows a long listing with the last lines being:
...
C:\Program Files\MATLAB\R2012b\java\jarext\webservices\ws_client_core\mw-service-client-core.jar
C:\Users\kkarapet\Documents\matlab toolbox\jdde\pretty-tools-JDDE-2.0.3.jar
DYNAMIC JAVA PATH
<empty>
So path seems to be set correctly. What am I doing wrong?
With the help of MathWorks support, I've found the answer. Here is how to make JDDE work with Matlab 2012b, without admin privileges:
Download and unpack JDDE files (DLLs and JAR) into some folder. Let's say it's $path-to-jdde$\.
In Matlab, type prefdir. Open the resulting directory and create two files there, javaclasspath.txt and javalibrarypath.txt.
In javaclasspath.txt, add $path-to-jdde$\pretty-tools-JDDE-2.0.3.jar.
In javalibrarypath.txt, add $path-to-jdde$\.
Restart Matlab.
Now call ddeConv = com.pretty_tools.dde.client.DDEClientConversation; and start using the created object as described in JavaDoc. E.g. to connect to Zemax, run Zemax and then in call ddeConv.connect('Zemax', 'abc').
Step 2 above can only be done starting Matlab version R2012b. With an older version, if you have the write rights on the Matlab installation directory, you should be able to replace step 2 by editing the files librarypath.txt and classpath.txt in $MATLABROOT$\toolbox\local. I could not verify it so if you confirm it please let me know in the comment below.
I am helping to code a stop-motion program that is to be cross platform, and on windows it works great. For those who do not know, stop motion is just a fancy term for animation. This program allows users to plug in Nikons, Canons, and Webcams into the computer, and have the program display a live view of the scene, and then have the ability to manually control the camera from there. Included is a framework file from canon for the camera, with a path defined as shown
import com.sun.jna.Native;
initialization and such
public static EdSdkLibrary EDSDK = (EdSdkLibrary) Native.loadLibrary("Macintosh/EDSDK.framework/EDSDK",EdSdkLibrary.class, options);
The error is thrown at the "public static int..." saying that the image is not found. I have tried numerous times redefining the path, moving the framework, and using various other frameworks identical to the one I'm using. Remember, this works flawlessly on Windows, but on Mac there is a problem.
Are frameworks different on macs, or are they to be defined differently? I have looked and found no other solutions.
EDIT: Okay, I defined the path and it now has this symbol > with no text next to it. WHat do I do now?
EDIT: It is saying that this % is not a command. Without it, it still fails to work.
JNA will successively attempt to load frameworks from ~/Library/Frameworks, /Library/Frameworks, and /System/Library/Frameworks, based on the core framework name (EDSDK in this case).
If the loadLibrary call succeeds, then the library was found. If the library was not found, you'll get an UnsatisfiedLinkError.
Frameworks are basically bundles of a shared library with other resources; ESDK.framework/ESDK is the actual shared library (for frameworks, OSX omits the "dyld" suffix normally found on a shared library on OSX).
EDIT
Here's how to make a symlink so that the paths look more like what JNA is expecting. From a terminal (run Terminal.app):
% ln -s /your/complete/path/to/Macintosh/EDSDK.framework ~/Library/Frameworks/EDSDK.framework
When this is done successfully, you should see the following when listing (ls) the symlink:
% ls -l ~/Library/Frameworks/EDSDK.framework
lrwxrwxr-x 1 YOU YOU 50 Mar 31 01:13 /Users/YOU/Library/Frameworks/EDSDK.framework -> /your/complete/path/to/Macintosh/EDSDK/Framework/EDSDK.framework
You should see the symlink path (where JNA will look) on the left, with the path to the real file on the right. If not, delete the symlink file and try again. Note that you may need to create the directory ~/Library/Frameworks first; it may not yet exist.
Finally, make sure that the library you're trying to load matches the VM you're trying to load with; 64-bit with 64-bit, 32-bit with 32-bit. Canon does not provide a universal binary of their library, so you'll need to point to one or the other or merge the two using lipo.
Not really an answer, but more information on the same problem, which I'm experiencing myself.
I can add that JNA will find my frameworks if they're in one of the standard public locations an executable looks for its frameworks, i.e.
~/Library/Frameworks - (public frameworks for the use of the current user)
/Library/Frameworks - (public frameworks for the use of any user)
/System/Library/Frameworks - (public system frameworks)
However, If I want my custom framework to be private - i.e. - not discoverable to other processes than my java vm -- then for some reason JNA doesn't do it.
I know MacOS dynamic loader, when trying to locate a library/framework for any normal (native) MacOS process, does NOT start searching the above locations, but first within several standard "private" locations: (also known as rpath search-path)
in the "Frameworks" directory at the same location as the binary from which the process was loaded: e.g. path/to/my/binary/Frameworks/mySDK.framework
in the "Frameworks" directory at the place where dynamic loader loaded the process (in Application bundles, that would be the myApp.app/Contents/Frameworks/mySDK.framework folder.
So, you can usually create a 'Frameworks' directory of your own right next to your binary, and place your framework in it.
However - JNA misses that. I tried to create a "Frameworks" directory within the "Zulu" - in zulu-11.jre/Contents/Home/bin right next to the 'java' binary, and in other places - but JNA won't find in any of them.
I wonder why, and if there is any documentation for that.
The trick of installing a symlink to my custom framework in /Library/Frameworks may serve you, but I cannot allow other processes to find or load my framework.
I'm having this issue with an app I have written for a Scanner running windows mobile 5.0. I have no idea what it means, can anyone with some Java Cre-Me, windows mobile experience lend some assistance please??
Error given on execution:
java.lang.UnsatisfiedLinkError: no SymbolJavaApi in java.library.path
at java.lang.ClassLoader.loadLibraryInternal()
at java.lang.ClassLoader.loadLibrary()
at java.lang.Runtime.loadLibrary0()
at java.lang.System.loadLibrary()
at
at com.vmt.plugins.symbol.barcodescanner.services.ScannerImplementation.read()
at com.vmt.plugins.symbol.barcodescanner.ScannerPlugin.invoke()
at ScannerTest.startScanning()
at ScannerTest.createwindow()
at ScannerTest.main()
For UnsatisfiedLinkError, the JDK states:
Thrown if the Java Virtual Machine cannot find an appropriate
native-language definition of a method declared native.
That means that there is a method inside ScannerImplementation.read() that is a native call definition that it can't in the java.library.path or any system defined libraries.
What this means is that the DLL that is needed for your ScannerImplementation isn't registered in the Java LIB path and thus the JVM can't do a native call.
I hope this helps.
The Java class loader tries to access the Symbol API but can not find the required libraries in the given library path.
On a desktop system I'd say you need:
Either extend the class path accordingly or
Copy missing external DLLs to the path where your application resides
I'm sure that Symbol/Motorola has some examples where you can see how to do that - maybe you need to install the classes to the device first using a CAB file.
I'm coming from a .NET background and for that, there's a Symbol API CAB file which installs required DLLs to the device.
I'm on Windows 7 32bit, Java JRE6 31 installed and using Sikuli X 1.0rc3. I want to launch a test with sikuli-script.jar like this:
java -jar c:\sikuli\sikuli-script.jar test.sikuli
All I get is this error message:
java.lang.UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError:C:\sikuli\libs\VisionProxy.dll: Can't find dependent libraries
I have set all the environment variables needed, so my PATH looks like this:
PATH=...;C:\sikuli\libs;C:\Program Files\Java\jre6\bin
SIKULI_HOME=C:\sikuli
I can use the IDE and launch the tests there etc. But only if I use the Sikuli-IDE.exe the sikuli-ide.bat and sikuli-ide.jar don't work either. Always with the same error from above. So I think in the build process of the .exe file they added some magic, but I can't figure out what it is.
Does somebody have a similar problem? Or even a solution?
Update
As I wrote below, it works out of the box with my new computer. :D But maybe my solution can help someone.
Sikuli Team uses Launch4J to build the Sikuli-IDE.exe out of the sikuli-ide.jar. They use this config file. I modified it slightly and created a Sikuli-script.exe. It was pretty simple but I lost the config file unfortunately.
Hope I could help!
You must use a 32bit JRE version (I use jre-7u4-windows-i586.exe)
Download Sikuli IDE for Windows (I use "Sikuli X r930", portable version)
Unpack it and copy files to your project folder (I renamed it to "sikuli-ide", check image htt+p://i.stack.imgur.com/LSiQV.png)
Add sikuli-script.jar to the Referenced Libraries (Project > Properties > Java Build Path > Libraries, check image http://i.stack.imgur.com/N2SJ8.png)
Set PATH and SIKULI_HOME environment vars (Run > Run Configurations > Environment, check image http://i.stack.imgur.com/HboXk.png)
You're ready to go ;)
According to the docs
Thrown if the Java Virtual Machine cannot find an appropriate native-language definition of a method declared native.
What you need to do is use this command:
-Djava.library.path=pathToDLL
Which will add your DLL that is missing.
I'm using JNA and Java but I think this question affects any native-to-nonnative bridge.
I have a Java application which relies on lib1.dylib, and lib1.dylib relies on lib2.dylib.
I want to put everything inside of my .app file on Mac. I can easily put lib1.dylib inside and set java.classpath (or NativeLibrary.addSearchPath()) to tell the JVM where to find lib1.dylib. The trouble is, I don't know how to communicate that lib1.dylib's dependencies are also in the location I provided. The result is that lib1 is loaded fine, but then lib2 can't be found since it's not in the operating system's library path.
Anyone know how I can overcome this problem? I imagine it must come up plenty in big projects with large numbers of shared libraries.
I've come across this problem before, and have just run into it again today. You may be able to get around it by adding the VM argument "-Djava.library.path=/path/to/other/libs", but I seem to remember Java only uses that to search for the intial library and then uses the system PATH to look for any dependencies.
A few solutions I've tried before:
1) Use System.load(absolutePath) on the dependent library before loading your library. Doesn't make your program ultra-portable though, unless you always know where that library is going to be.
2) In a case where lib1 depends on lib2, I actually used SetCurrentDirectory (Windows, not sure of the Mac equivalent) in the native code before it linked to any of the dependent libs, and that seemed to work. Again, requires knowing where the other libs are.
3) On Windows, could dump the dependent libraries in c:\windows\system32, and it finds them.
A few helpful posts on a similar topic (Windows-specific, but I think the problem is the same):
http://www.realityinteractive.com/rgrzywinski/archives/000219.html
http://www.velocityreviews.com/forums/t387618-jni-library-path.html
I've found a solution for MacOSX based on the idea in (2) from Stew:
Using Mac's JarBundler (or the Ant task of the same name) set the workingdirectory variable to $JAVAROOT and make sure your dylibs are in the Contents/Resources/Java part of the .app. If you do this the dynamic linker will find all the dependency dylibs because it will be the present directory. Java will also find the original dylib (the one that has all the dependencies) for the same reason.
Ant code:
<target name="package_mac_app" depends="package_jar, compile_native" description="bundle the runnable jar into a Mac Application -- requires JarBundler ANT Task">
<taskdef name="jarbundler" classname="net.sourceforge.jarbundler.JarBundler"/>
<echo message="CREATING MAC .app EXECUTABLE"/>
<jarbundler dir="${dist}"
name="${appname}"
mainclass="myPackage.myMainClass"
icon="${icon_location}"
jvmversion="1.5+"
infostring="${appname}"
shortname="${appshortname}"
bundleid="${com.mycompany.mydepartment.myprogram}"
jar="${run_jar_location}"
workingdirectory="$JAVAROOT">
<javafilelist dir="${dylib_location}" files="my-lib.dylib"/>
<javafilelist dir="${dylib_location}" files="dependent-lib.dylib"/>
</jarbundler>
</target>