Good morning! I’ve been trying to get the JCuda tutorial provided here (http://www.jcuda.org/tutorial/TutorialIndex.html) running for a little while, but am running into issues with an UnsatisfiedLinkError.
I’m using Windows 10, 64-bit operating system, x64-based processor, JCuda 10.1.0 and CUDA version 10.1.
Here is the full stack trace:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error while loading native library "JCudaRuntime-10.1.0-windows-x86"
Operating system name: Windows 10
Architecture : x86
Architecture bit size: 32
---(start of nested stack traces)---
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError: no JCudaRuntime-10.1.0-windows-x86 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at jcuda.LibUtils.loadLibrary(LibUtils.java:143)
at jcuda.runtime.JCuda.initialize(JCuda.java:427)
at jcuda.runtime.JCuda.<clinit>(JCuda.java:411)
at main.JCudaRuntimeTest.main(JCudaRuntimeTest.java:11)
Stack trace from the attempt to load the library as a resource:
java.io.IOException: No resource found with name '/lib/JCudaRuntime-10.1.0-windows-x86.dll'
at jcuda.LibUtils.writeResourceToFile(LibUtils.java:323)
at jcuda.LibUtils.loadLibraryResource(LibUtils.java:255)
at jcuda.LibUtils.loadLibrary(LibUtils.java:158)
at jcuda.runtime.JCuda.initialize(JCuda.java:427)
at jcuda.runtime.JCuda.<clinit>(JCuda.java:411)
at main.JCudaRuntimeTest.main(JCudaRuntimeTest.java:11)
---(end of nested stack traces)---
at jcuda.LibUtils.loadLibrary(LibUtils.java:193)
at jcuda.runtime.JCuda.initialize(JCuda.java:427)
at jcuda.runtime.JCuda.<clinit>(JCuda.java:411)
at main.JCudaRuntimeTest.main(JCudaRuntimeTest.java:11)
I have downloaded the files attached to JCuda and JCudnn, version 10.1.0 from here: http://www.jcuda.org/downloads/downloads.html and extracted the folder. I put the folder location in PATH, CLASSPATH, and passed it in with -Djava.library.path, to no avail.
Something I did notice is that it’s looking for windows-x86, and not windows-x86_64, but I’m not sure how I would resolve this. It’s also possible there’s something else obvious that I’m missing. Any help would be much appreciated, thank you!
First, a short aside: It’s OK to try and set things up manually. But with Maven, using JCuda eventually usually boils down to adding the JCuda dependency. There is also an example for a „standalone“ Maven project is at https://github.com/jcuda/jcuda-examples (I’d have to update the version number there), but with an IDE, it’s usually even simpler.
But in your case, the root of the problem seems to be what you already pointed out:
What does it print for you when you type
java -version
at the console? The output should be something like
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
(the important part being that it talks about „64-Bit“ at some point). If there’s nothing that says „64 bit“, then this might just mean that you’re using a 32bit version of Java.
With a 64 bit version, it should work. If not, we can investigate this further.
Hi Marco, thanks for the assistance! I did see „64-Bit Server VM“ in the description when I typed java -version, but after checking, I discovered that there were multiple versions of Java installed on this computer (including a 32 bit one). After cleaning those up, I was able to get the tutorial code to execute.
To address your short aside: my original goal was to incorporate JCuda into an existing project that uses gradle, but after running into the previous issue, I started a new project to resolve it in a vacuum. Once I confirmed that it was the Java version that was the issue, I cloned the jcuda-example-maven project you linked as an intermediate step (it was very helpful, thank you!). I was almost able to run that out of the box after updating the version to 10.1.0. However, this line causes the exception included below (commenting it out resulted in success).
JCusparse.setExceptionsEnabled(true);
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error while loading native library "JCusparse-10.1.0-windows-x86_64"
Operating system name: Windows 10
Architecture : amd64
Architecture bit size: 64
---(start of nested stack traces)---
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError: no JCusparse-10.1.0-windows-x86_64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at jcuda.LibUtils.loadLibrary(LibUtils.java:143)
at jcuda.jcusparse.JCusparse.initialize(JCusparse.java:77)
at jcuda.jcusparse.JCusparse.<clinit>(JCusparse.java:62)
at org.jcuda.example.maven.JCudaExampleMaven.main(JCudaExampleMaven.java:25)
Stack trace from the attempt to load the library as a resource:
java.lang.UnsatisfiedLinkError: C:\Users\lklein\AppData\Local\Temp\JCusparse-10.1.0-windows-x86_64.dll: The specified procedure could not be found
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at jcuda.LibUtils.loadLibraryResource(LibUtils.java:260)
at jcuda.LibUtils.loadLibrary(LibUtils.java:158)
at jcuda.jcusparse.JCusparse.initialize(JCusparse.java:77)
at jcuda.jcusparse.JCusparse.<clinit>(JCusparse.java:62)
at org.jcuda.example.maven.JCudaExampleMaven.main(JCudaExampleMaven.java:25)
---(end of nested stack traces)---
at jcuda.LibUtils.loadLibrary(LibUtils.java:193)
at jcuda.jcusparse.JCusparse.initialize(JCusparse.java:77)
at jcuda.jcusparse.JCusparse.<clinit>(JCusparse.java:62)
at org.jcuda.example.maven.JCudaExampleMaven.main(JCudaExampleMaven.java:25)
I don’t believe I need jcusparse for what I’m working on, but wanted to mention in case it was useful for you, since it was only that one.
Finally, I translated the maven dependencies to the gradle format and included them in my actual project. I ended up getting project resolve errors, where ${jcuda.os} and ${jcuda.arch} were being used as is, without having their values substituted. I searched around some and found this link: https://github.com/jcuda/jcuda-main/issues/16. I used the provided gradle code to resolve the issue. Since it’s been a few years since that thread, I was wondering whether there’s a more concise solution available that I’ve missed?
The details of the new UnsatisfiedLinkError from JCusparse say " The specified procedure could not be found", which usually indicates that the JCuda version and the installed CUDA version do not match. It might not be immediately relevant for you, but to be sure: Do you also have any older CUDA versions installed?
Regarding Gradle: I’ve never actively used Gradle, and the issue that you linked to was what eventually ended up in https://github.com/jcuda/jcuda-main/blob/master/USAGE.md#using-jcuda-with-gradle , but I have to rely on what others are providing at this point: I basically used what was described in the issue, without understanding it in all depth…
(Any hints about how the usage with Gradle could be made simpler would be appreciated, though…)
I did have an older version of CUDA (9.2) installed at one point, but uninstalled it when I moved to 10.1. I confirmed that there’s currently only „v10.1“ in C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\ and no references to any other version in my environment variables.
Unfortunately, I wasn’t able to find a simpler gradle solution this week, but if I do in the future I will let you know.
In the worst case, the current error (about the procedure that was not found) might be an instance of NVIDIA removing functions without updating the version number accordingly. At least, I remember some hiccups with JCusolver (mentioned in CUDA 10.1 · Issue #29 · jcuda/jcuda-main · GitHub ). For example, they removed certain functions between CUDA 10.1.105 and CUDA 10.1.168 - so both are „Version 10.1“, but with a different set of functions
(Until now, it’s only a guess, because it would explain the observed behavior.)
I will certainly not go the extra mile and create matching JCuda versions for each and every CUDA build/patch version that they release. But if this becomes an issue for you, I can have another look at the release notes of the CUDA versions that I used for compiling the natives, and your exact CUDA version (which might be a later build, despite the same version number), or look at the actual headers and .LIB exports to see whether they might just have silently changed a function signature.
