I am using Weka 3.7.12. Once I updated all available packages in Weka, I am not able to open classification dialog in Weka. I am able to load and pre-process data in Weka. But, whenever i want to perform classification, Weka is producing following error:
Exception in thread "Thread-159" java.lang.UnsatisfiedLinkError:
org.rosuda.JRI.Rengine.rniSetupR([Ljava/lang/String;)I
org.rosuda.JRI.Rengine.rniSetupR(Native Method)
org.rosuda.JRI.Rengine.setupR(Rengine.java:170)
org.rosuda.JRI.Rengine.run(Rengine.java:635) at
org.rosuda.JRI.Rengine.rniSetupR(Native Method) at
org.rosuda.JRI.Rengine.setupR(Rengine.java:170) at
org.rosuda.JRI.Rengine.run(Rengine.java:635)
Please anybody help me out. Thanks in advance.
The UnsatisfiedLinkError is thrown when an application attempts to load a native library like .so in Linux, .dll on Windows or .dylib in Mac and that library does not exist. Specifically, in order to find the required native library, the JVM looks in both the PATH environment variable and the java.library.path system property.
Related
I am trying to run a test file InspectVM from libguestfs library inorder to have accesss to a disk image in windows. However, I have the following errors on my console
run:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no guestfs_jni in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at madjava.com.redhat.et.libguestfs.GuestFS.<clinit>(GuestFS.java:51)
at madjava.examples.InspectVM.main(InspectVM.java:30)
C:\Users\CyberSOFONET\AppData\Local\NetBeans\Cache\8.2\executor-snippets\run.xml:53: Java returned: 1
BUILD FAILED (total time: 0 seconds)#
I searched allover the internet and find that I should set java.libraly.path pointing to location of the guestfs_jni. my major problem is that I do not have any file with that name guestfs_jni. Do I need to make one myself or can I find it somewhere. any kind of help is appriciated. am a newbie in JNI so I dont have much imformation on it
You're looking for a file called guestfs_jni.dll. Usually the native library comes with the jar file.
From http://libguestfs.org/guestfs-java.3.html:
Libguestfs for Java is a Java Native Interface (JNI) extension, supplied in three parts: libguestfs.jar, libguestfs-VERSION.jar, libguestfs_jni.so, libguestfs.so
So the distribution comes with libguest_jni.so which ist for Linux and not for Windows. IIRC, there is no libguestfs for Windows. So you would first have to find out if it is even possible to compile libguestfs using Cygwin and if yes build it yourself.
If you're on Windows 10 you could try installing libguestfs and a Java runtime for the Linux subsystem and run inside the subsystem.
I am trying to setup mavenized JCUDA for a project that I am working on and am running into issues with telling java where to locate the library files.
Setting up and getting maven to build the .jar and .dll files has worked fine, I can see the correctly named .dll files in project\target\lib and I am setting my native library location to this folder.
The error I get when trying to run one of the programs from JCUDA JCublasSample.java (www.jcuda.org/samples/JCublasSample.java) is:
Creating input data... Performing Sgemm with Java... Performing Sgemm
with JCublas...
Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not
load the native library.
Error while loading native library "JCublas-windows-x86_64" with base
name "JCublas" Operating system name: Windows 7 Architecture :
amd64 Architecture bit size: 64
Stack trace from the attempt to load the library as a resource:
java.lang.NullPointerException: No resource found with name
'/lib/JCublas-windows-x86_64.dll'
at jcuda.LibUtils.loadLibraryResource(LibUtils.java:149) at
jcuda.LibUtils.loadLibrary(LibUtils.java:83) at
jcuda.jcublas.JCublas.initialize(JCublas.java:93) at
jcuda.jcublas.JCublas.(JCublas.java:81) at
JCublasSample.sgemmJCublas(JCublasSample.java:64) at
JCublasSample.testSgemm(JCublasSample.java:49) at
JCublasSample.main(JCublasSample.java:25)
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError:
C:\Users\kristoffer.bernhem\git\SMlocalizer\target\lib\JCublas-windows-x86_64.dll:
Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method) at
java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) at
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) at
java.lang.Runtime.loadLibrary0(Runtime.java:870) at
java.lang.System.loadLibrary(System.java:1122) at
jcuda.LibUtils.loadLibrary(LibUtils.java:94) at
jcuda.jcublas.JCublas.initialize(JCublas.java:93) at
jcuda.jcublas.JCublas.(JCublas.java:81) at
JCublasSample.sgemmJCublas(JCublasSample.java:64) at
JCublasSample.testSgemm(JCublasSample.java:49) at
JCublasSample.main(JCublasSample.java:25) at
jcuda.LibUtils.loadLibrary(LibUtils.java:128) at
jcuda.jcublas.JCublas.initialize(JCublas.java:93) at
jcuda.jcublas.JCublas.(JCublas.java:81) at
JCublasSample.sgemmJCublas(JCublasSample.java:64) at
JCublasSample.testSgemm(JCublasSample.java:49) at
JCublasSample.main(JCublasSample.java:25)
As explained by Guenther, the problem lies in supporting .dll files that are lacking. How would I go about sorting this error out?
This is being run in windows 7 (64bit) and run with JDK1.8.0_91.
When i'm trying to load the .so file from the Java, i'm getting error like this.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no yeslib.so in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1047)
at com.rct.micros.util.GetCustClass.getScratchCode(GetCustClass.java:76)
at com.rct.micros.util.GetCustClass.main(GetCustClass.java:39)
I have tried System.load(absoulte path) and System.loadLibrary(sofilename). Both are giving the same error. When i copy this so file into usr/lib/jvm package, it is working..
can anyone help how to get this solved using Java. i'm running on linux box.
It's possible that the library is on your path, but it can't be loaded for some other reason.
A trick I've used to debug problems like this is to run java -Xrunsofilename
-Xrun is the JVM option to load JVMPI libraries (the old profiling interface). If it succeeds, it will load the library and complain that it's not an agent library. But if it fails (hopefully!) it will print an error message. This is usually a more descriptive error message than what you get from the UnsatisfiedLinkError.
I got a .jar file from a code that works on Windows, and I'm trying to run it on Linux, but I keep getting this message, and don't know what to do.
Exception in thread "Thread-0" java.lang.UnsatisfiedLinkError: no usbJava in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1856)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at ch.ntb.usb.LibusbJava.<clinit>(LibusbJava.java:366)
at ch.ntb.usb.USB.init(USB.java:315)
at ch.ntb.usb.USB.getBus(USB.java:296)
at ch.ntb.usb.Device.initDevice(Device.java:102)
at ch.ntb.usb.Device.open(Device.java:222)
at TransmitterModuleHIDInterface.run(TransmitterModuleHIDInterface.java:28)
at java.lang.Thread.run(Thread.java:722)
I'm using the Java wrapper for the libusb-0.1 (I followed the installation instructions here).
Any help would be really appreciated!
You need to create a link to the shared library, as per the Linux installation instructions:
http://libusbjava.sourceforge.net/wp/?page_id=8
If you're having trouble building the shared library this might be of some help:
http://me.opengroove.org/2010/01/libusbjavaso.html
The sources for the library itself is under /libusbjava/trunk/LibusbJava/ in the SVN source tree.
When using the Java Attach API, I'm getting the following link error on Linux (tried it on different machines) only:
Exception in thread "main" java.lang.UnsatisfiedLinkError: sun.tools.attach.WindowsAttachProvider.tempPath()Ljava/lang/String;
at sun.tools.attach.WindowsAttachProvider.tempPath(Native Method)
at sun.tools.attach.WindowsAttachProvider.isTempPathSecure(WindowsAttachProvider.java:74)
at sun.tools.attach.WindowsAttachProvider.listVirtualMachines(WindowsAttachProvider.java:58)
at com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:134)
at sun.tools.jconsole.LocalVirtualMachine.getAttachableVMs(LocalVirtualMachine.java:151)
at sun.tools.jconsole.LocalVirtualMachine.getAllVirtualMachines(LocalVirtualMachine.java:110)
...
Interestingly, on Solaris and Windows it's working out of the box.
I tried out several combinations of specifying java.library.path to point to the directory which contains the libattach.so but with no luck.
What's wrong here?
And as a bonus question: Is there a way to see which native library is actually bound to a java class?
Different AttachProvider are used on different platforms. On Linux, it shouldn't use sun.tools.attach.WindowsAttachProvider. It is for Windows.
[solaris] sun.tools.attach.SolarisAttachProvider
[windows] sun.tools.attach.WindowsAttachProvider
[linux] sun.tools.attach.LinuxAttachProvider
This is configured in a resource file META-INF\services\com.sun.tools.attach.spi.AttachProvider (typically this file exists in tools.jar). It will search CLASSPATH to get first occurrence of this resource file and read the AttachProvider implementation class from it.
So you can probably resolve this problem by search sun.tools.attach.WindowsAttachProvider in your CLASSPATH. Possibly you have included a tools.jar from Windows.