Again: Unsatisfied Link Error

After 3 days fighting I am defeated. I have newly installed JCuda following meticuously the instructions provided on http://www.jcuda.org/. I keep on getting the „java.lang.UnsatisfiedLinkError: no JNvrtc-10.1.0-windows-x86_64 in java.library.path: …“ error. I even extracted the three DLLs in jcuda-natives-10.1.0-windows-x86_64.jar. That only led to a new error: ‚java.lang.UnsatisfiedLinkError: C:\Users\odiep\AppData\Local\Temp\JNvrtc-10.1.0-windows-x86_64.dll: Can’t find dependent libraries‘.
I am lost now. I am totally aware that this was a topic 10 years (!!) ago already (see Marco’s post/FAQ: JCuda FAQ - Please read before posting).

What can I do? Any suggestion?
(Interesting: I have a lenovo with a Quadro RTX 3000 GPU and some Intel CPU. The console output speaks of ‚Architecture : amd64‘. AMD? Don’t know whether this has a bearing on the problem.).
I have the Cuda toolkit 11.1 and JCuda 10.1. Could it be that this does not fit together?
I should also mention that I use IntelliJ IDEA as workbench.

Marco: this must be boring for you. But I am desparate by now. I hope you can help me.

Here is the console output:

C:\tools\JDK\openjdk-11+28_windows-x64_bin\jdk-11\bin\java.exe „-javaagent:C:\tools\IntelliJIdea\IntelliJ IDEA Community Edition 2020.2.3\lib\idea_rt.jar=63163:C:\tools\IntelliJIdea\IntelliJ IDEA Community Edition 2020.2.3\bin“ -Dfile.encoding=UTF-8 -classpath C:\Users\odiep\Documents\Programs\CUDA\CUDA0\out\production\CUDA0;C:\tools\JavaFX\javafx-sdk-11.0.2\lib\javafx-swt.jar;C:\tools\JavaFX\javafx-sdk-11.0.2\lib\javafx.base.jar;C:\tools\JavaFX\javafx-sdk-11.0.2\lib\javafx.controls.jar;C:\tools\JavaFX\javafx-sdk-11.0.2\lib\javafx.fxml.jar;C:\tools\JavaFX\javafx-sdk-11.0.2\lib\javafx.graphics.jar;C:\tools\JavaFX\javafx-sdk-11.0.2\lib\javafx.media.jar;C:\tools\JavaFX\javafx-sdk-11.0.2\lib\javafx.swing.jar;C:\tools\JavaFX\javafx-sdk-11.0.2\lib\javafx.web.jar;C:\Users\odiep\AppData\Roaming\JetBrains\IdeaIC2020.2\plugins\Kotlin\kotlinc\lib\kotlin-stdlib.jar;C:\Users\odiep\AppData\Roaming\JetBrains\IdeaIC2020.2\plugins\Kotlin\kotlinc\lib\kotlin-reflect.jar;C:\Users\odiep\AppData\Roaming\JetBrains\IdeaIC2020.2\plugins\Kotlin\kotlinc\lib\kotlin-test.jar;C:\Users\odiep\AppData\Roaming\JetBrains\IdeaIC2020.2\plugins\Kotlin\kotlinc\lib\kotlin-stdlib-jdk7.jar;C:\Users\odiep\AppData\Roaming\JetBrains\IdeaIC2020.2\plugins\Kotlin\kotlinc\lib\kotlin-stdlib-jdk8.jar;C:\tools\JCuda-All-10.1.0\jcuda-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcudnn-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcufft-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcublas-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcurand-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jnvgraph-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcusolver-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcusparse-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcuda-common-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcuda-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcuda-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcuda-natives-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcudnn-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcudnn-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcudnn-natives-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcufft-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcufft-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcufft-natives-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcublas-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcublas-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcublas-natives-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcurand-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcurand-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcurand-natives-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jnvgraph-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jnvgraph-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jnvgraph-natives-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcusolver-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcusolver-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcusolver-natives-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcusparse-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcusparse-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcusparse-natives-10.1.0.jar;C:\tools\JCuda-All-10.1.0\jcuda-common-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcuda-common-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcuda-natives-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcuda-natives-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcudnn-natives-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcudnn-natives-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcufft-natives-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcufft-natives-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcublas-natives-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcublas-natives-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcurand-natives-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcurand-natives-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jnvgraph-natives-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jnvgraph-natives-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcusolver-natives-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcusolver-natives-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcusparse-natives-10.1.0-javadoc.jar;C:\tools\JCuda-All-10.1.0\jcusparse-natives-10.1.0-sources.jar;C:\tools\JCuda-All-10.1.0\jcuda-natives-10.1.0-apple-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcuda-natives-10.1.0-linux-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcudnn-natives-10.1.0-apple-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcudnn-natives-10.1.0-linux-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcufft-natives-10.1.0-apple-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcufft-natives-10.1.0-linux-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcublas-natives-10.1.0-apple-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcublas-natives-10.1.0-linux-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcuda-natives-10.1.0-windows-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcurand-natives-10.1.0-apple-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcurand-natives-10.1.0-linux-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcudnn-natives-10.1.0-windows-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcufft-natives-10.1.0-windows-x86_64.jar;C:\tools\JCuda-All-10.1.0\jnvgraph-natives-10.1.0-apple-x86_64.jar;C:\tools\JCuda-All-10.1.0\jnvgraph-natives-10.1.0-linux-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcublas-natives-10.1.0-windows-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcurand-natives-10.1.0-windows-x86_64.jar;C:\tools\JCuda-All-10.1.0\jcusolver-natives-10.1.0-apple-x86_64.jar;
C:\tools\JCuda-All-10.1.0\jcusolver-natives-10.1.0-linux-x86_64.jar;
C:\tools\JCuda-All-10.1.0\jcusparse-natives-10.1.0-apple-x86_64.jar;
C:\tools\JCuda-All-10.1.0\jcusparse-natives-10.1.0-linux-x86_64.jar;
C:\tools\JCuda-All-10.1.0\jnvgraph-natives-10.1.0-windows-x86_64.jar;
C:\tools\JCuda-All-10.1.0\jcusolver-natives-10.1.0-windows-x86_64.jar;
C:\tools\JCuda-All-10.1.0\jcusparse-natives-10.1.0-windows-x86_64.jar;
C:\Users\odiep\Documents\Programs\MyLibs\MyApplication01.jar;
C:\tools\jcudaUtils-0.0.4.jar
cuda01.Cuda01Kt

Exception in thread „main“ java.lang.UnsatisfiedLinkError: Error while loading native library „JNvrtc-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 JNvrtc-10.1.0-windows-x86_64 in java.library.path: [C:\tools\JDK\openjdk-11+28_windows-x64_bin\jdk-11\bin, C:\Windows\Sun\Java\bin, C:\Windows\system32, C:\Windows, C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.1\bin, C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.1\libnvvp, C:\Windows\system32, C:\Windows, C:\Windows\System32\Wbem, C:\Windows\System32\WindowsPowerShell\v1.0, C:\Windows\System32\OpenSSH, C:\Program Files\NVIDIA Corporation\Nsight Compute 2020.2.0, C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common, C:\tools\JDK\openjdk-11+28_windows-x64_bin\jdk-11\bin, C:\Program Files\dotnet, C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64, C:\Users\odiep\AppData\Local\Microsoft\WindowsApps, C:\tools\IntelliJIdea\IntelliJ IDEA Community Edition 2020.2.3\bin, ., C:\Users\odiep.dotnet\tools, C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64, ., .]
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
at java.base/java.lang.System.loadLibrary(System.java:1867)
at jcuda.LibUtils.loadLibrary(LibUtils.java:143)
at jcuda.nvrtc.JNvrtc.(JNvrtc.java:59)
at cuda01.Cuda01Kt.main(Cuda01.kt:21)
at cuda01.Cuda01Kt.main(Cuda01.kt)
Stack trace from the attempt to load the library as a resource:
java.lang.UnsatisfiedLinkError: C:\Users\odiep\AppData\Local\Temp\JNvrtc-10.1.0-windows-x86_64.dll: Can’t find dependent libraries
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2487)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
at java.base/java.lang.Runtime.load0(Runtime.java:767)
at java.base/java.lang.System.load(System.java:1831)
at jcuda.LibUtils.loadLibraryResource(LibUtils.java:260)
at jcuda.LibUtils.loadLibrary(LibUtils.java:158)
at jcuda.nvrtc.JNvrtc.(JNvrtc.java:59)
at cuda01.Cuda01Kt.main(Cuda01.kt:21)
at cuda01.Cuda01Kt.main(Cuda01.kt)
—(end of nested stack traces)—

at jcuda.LibUtils.loadLibrary(LibUtils.java:193)
at jcuda.nvrtc.JNvrtc.<clinit>(JNvrtc.java:59)
at cuda01.Cuda01Kt.main(Cuda01.kt:21)

at cuda01.Cuda01Kt.main(Cuda01.kt)

In meantime I have changed the Cuda Toolkit version from 11 to 10 but to no avail. Same Error.

That’s the case. It’s a pity that you seem to have struggled with that for so long. Maybe I should somehow make clearer that the versions have to match. The core of the error message is

java.lang.UnsatisfiedLinkError: C:\Users\odiep\AppData\Local\Temp\JNvrtc-10.1.0-windows-x86_64.dll:
Can’t find dependent libraries

(Although the actual library - JNvtrc in this case - is „arbitrary“, so to speak)

A bit simplified, to illustrate the point: JCuda X.Y contains 1:1 bindings for all functions in CUDA X.Y. In CUDA 11, NVIDIA might have removed functions from that still had been available in CUDA 10. The corresponding functions from JCuda 10 wouldn’t know what to do when this function is called.

An aside: It would theoretically be possible to cover such a case, and throw an UnsupportedOperationException when a function was removed. But this would require lots of effort and basically a complete overhaul of the implementation, and I cannot do this just so, in my spare time.

The topic is difficult beyond that, in many ways. In Loading CUDA binaries · Issue #36 · jcuda/jcuda-main · GitHub someone suggested to ship the actual CUDA libraries together with JCuda. But this has many caveats, starting with the question of how to detect compatibility (you certainly couldn’t use CUDA 11 if you had a graphics card driver from 2012 installed), the fact that the CUDA libraries may easily be a gigabyte for one operating system, and some others that I mentioned in that issue.

So the bottom line is: When you have installed CUDA X.Y, you have to use JCuda X.Y. Sorry for the hassle.

Hi. I did install the Cuda Toolkit 10.2 and uninstalled the 11.1 version. But it is hard to get rid of it. The classpath used still contains the 11.1 version (actually bot version):

[C:\tools\JDK\openjdk-11+28_windows-x64_bin\jdk-11\bin, C:\Windows\Sun\Java\bin,
C:\Windows\system32, C:\Windows, C:\Program Files\NVIDIA GPU Computing
Toolkit\CUDA\v10.2\bin, C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\libnvvp,
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.1\bin, C:\Program Files\NVIDIA GPU
Computing Toolkit\CUDA\v11.1\libnvvp, ., C:\Windows\system32, C:\Windows,
C:\Windows\System32\Wbem, C:\Windows\System32\WindowsPowerShell\v1.0,
C:\Windows\System32\OpenSSH, C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common,
C:\tools\JDK\openjdk-11+28_windows-x64_bin\jdk-11\bin, C:\Program Files\dotnet, C:\Program
Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64,
C:\Program Files\NVIDIA Corporation\Nsight Compute 2019.5.0,
C:\Users\odiep\AppData\Local\Microsoft\WindowsApps, C:\tools\IntelliJIdea\IntelliJ IDEA
Community Edition 2020.2.3\bin, ., C:\Users\odiep.dotnet\tools, C:\Program Files
(x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64, ., .]

I have introduced a CLASSPATH environment variable without the reference to the 11.1 version, but somehow the Java runtime still knows about the 11.1 version and I don’t know where from. I guess I need to find out that until the 11.1 version does not appear anymore in the class path reported in the error message. Only then I can claim, that I am not somehow using 11.1 (which you have confirmed, wouldn’t work).

Your’re talking about the „classpath“, but I assume that you refer to the PATH environment variable, right? (That’s what is used for looking up dependent libraries).

I think that the CUDA uninstaller should reset/update the PATH environment variable automatically. If this is not the case: Look for „Environment Variables“ (Umgebungsvariablen) in the System Settings (Systemsteuerung), select ~„Change System Environment Variables“ (Systemumbegungsvarablen bearbeiten). In the Dialog, select „Environment Variables“ (Umgebungsvariablen…) in the lower right, and in the lower part (~„System Variables“ (Systemvariablen)), modify the Path variable to not include anything that is not related to the desired CUDA version.

Hi Marco.
I went through all that.
The ‚Path‘ Environment variable looks ok to me (no reference to Cuda 11, instead Cuda 10, which I have installed).
The java.library.path shown in the error message matches the ‚Path‘ by and large (albeit not being exactly the same). The compilation works ok and the error comes at run time. I have run out of ideas.
I have added below:

  • the ‚Path‘ Environment variable
  • the runtime error
  • the Java Code (really just a two liner)
  • the script (so, I am running it from command line to exclude the possibility that the workbench I use plays me tricks)

The ‚Path‘ Environment variable:
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\libnvvp;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\tools\JDK\openjdk-11+28_windows-x64_bin\jdk-11\bin;C:\Program Files\dotnet;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64;C:\Program Files\NVIDIA Corporation\Nsight Compute 2019.5.0;C:\tools\JCuda-All-10.1.0;

The error message:
java : Exception in thread „main“ java.lang.UnsatisfiedLinkError: Error while loading native
library „JNvrtc-10.1.0-windows-x86_64“
In C:\Users\odiep\Documents\Programs\CUDA\CUDACommandline\Cuda02\cuda02.ps1:17 Zeichen:1

  • java -cp $options Cuda02
  • CategoryInfo : NotSpecified: (Exception in th…windows-x86_64":String) [], Re moteException
  • FullyQualifiedErrorId : NativeCommandError

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 JNvrtc-10.1.0-windows-x86_64 in java.library.path:
[C:\tools\JDK\openjdk-11+28_windows-x64_bin\jdk-11\bin, C:\Windows\Sun\Java\bin,
C:\Windows\system32, C:\Windows, C:\Program Files\NVIDIA GPU Computing
Toolkit\CUDA\v10.2\bin, C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\libnvvp,
C:\Windows\system32, C:\Windows, C:\Windows\System32\Wbem,
C:\Windows\System32\WindowsPowerShell\v1.0, C:\Windows\System32\OpenSSH, C:\Program Files
(x86)\NVIDIA Corporation\PhysX\Common, C:\tools\JDK\openjdk-11+28_windows-x64_bin\jdk-11\bin,
C:\Program Files\dotnet, C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64, C:\Program Files\NVIDIA
Corporation\Nsight Compute 2019.5.0, C:\tools\JCuda-All-10.1.0,
C:\Users\odiep\AppData\Local\Microsoft\WindowsApps, C:\tools\IntelliJIdea\IntelliJ IDEA
Community Edition 2020.2.3\bin, ., C:\Users\odiep.dotnet\tools, C:\Program Files
(x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64,
C:\tools\JCuda-All-10.1.0, ., .]
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
at java.base/java.lang.System.loadLibrary(System.java:1867)
at jcuda.LibUtils.loadLibrary(LibUtils.java:143)
at jcuda.nvrtc.JNvrtc.(JNvrtc.java:59)
at Cuda02.main(Cuda02.java:18)
Stack trace from the attempt to load the library as a resource:
java.lang.UnsatisfiedLinkError:
C:\Users\odiep\AppData\Local\Temp\JNvrtc-10.1.0-windows-x86_64.dll: Can’t find dependent
libraries
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2487)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
at java.base/java.lang.Runtime.load0(Runtime.java:767)
at java.base/java.lang.System.load(System.java:1831)
at jcuda.LibUtils.loadLibraryResource(LibUtils.java:260)
at jcuda.LibUtils.loadLibrary(LibUtils.java:158)
at jcuda.nvrtc.JNvrtc.(JNvrtc.java:59)
at Cuda02.main(Cuda02.java:18)
—(end of nested stack traces)—
at jcuda.LibUtils.loadLibrary(LibUtils.java:193)
at jcuda.nvrtc.JNvrtc.(JNvrtc.java:59)
at Cuda02.main(Cuda02.java:18)

The java Code:

import jcuda.*;
import jcuda.runtime.*;
import jcuda.driver.*;
import jcuda.driver.JCudaDriver.*;
import jcuda.nvrtc.JNvrtc;
import jcuda.nvrtc.JNvrtc.*;
import jcuda.nvrtc.nvrtcProgram;

public class Cuda02
{
	public static void main(String args[])
    	{
            JCudaDriver.setExceptionsEnabled(true);

            // this is the statement that throws the 'UnsatisfiedLinkError' at runtime
            JNvrtc.setExceptionsEnabled(true);
    	}
}

The script (Powershell):

$workDirectory="C:\Users\odiep\Documents\Programs\CUDA\CUDACommandline\Cuda02"
$JavaProgram="Cuda02"

cd $workDirectory

$jar1="jcuda-10.1.0.jar"
$jar2="jcuda-natives-10.0.1-windows-x86_64.jar"
$tools = "C:\tools\JCuda-All-10.1.0"
$options = $options = ".;" + $tools+"\"+$jar1 +";"+$tools+"\"+$jar2

"Start Compile"
"With options:"+$options
javac -cp $options Cuda02.java
"End Compile"

"Start Run"
java  -cp $options Cuda02

I had another look at this: It still says that a dependent library is not found. Unfortunately, it does not say which DLL it does not find.

However, a dumpbin /dependents JNvrtc-10.2.0-windows-x86_64.dll prints

nvrtc64_102_0.dll
KERNEL32.dll
ADVAPI32.dll

But a dumpbin /dependents JNvrtc-11.0.0-windows-x86_64.dll prints

nvrtc64_112_0.dll
KERNEL32.dll

I don’t exactly know what the ADVAPI32.dll is. It might be one of these beloved DLLs that the Visual Studio Linker sneaks in without any reason whatsoever. In the worst case, this is the DLL that is missing for you. A simple way of checking whether this file is present for you could be to just do a

dir C:\Windows\System32\advapi32.dll

on the console and see whether it is found. If it is not found, then this would explain the error.

(You could find this out by dropping the JNvrtc-10.2.0-windows-x86_64.dll into the https://www.dependencywalker.com/ - it may appear to be unresponsive for a while, but should eventually print the (large) dependency tree and indicate which DLLs are not found. But knowing that the file does not exist should be enough to pin down the reason for now).

BTW: I’m also on Windows 10, and for me, the file is present. If it is missing for your, then it might be part of some redistributables ( https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads ), but I’m not sure about that.

Sorry for the hassle. I can imagine that messing around with different CUDA installations/deinstallations is annoying, and it should of course not be so complicated: It should be possible to just add JCuda as a Maven Dependency, and it should „just work“. But there are always caveats. Let’s hope we can resolve this without much more effort for you.

Thanks for the hints. The advapi32.dll is there - OK, so that’s not it. I have already taken the plan to inspect the jars a bit closer. I have already installed the dependencywalker. Good you warned me that it takes it time. I have to travel for a few days, so it has to wait for now.

Hi. I might have found the problem. JNvrtc-10.1.0-windows-x86_64 is dependent on nvrtc64_101_0.dll. I do not have that library, but instead I have in C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin the file nvrtc64_102_0.dll.
So, apparently I am using CUDA 10.2 and JCuda 10.1. I guess I will try to get Cuda 10.1 now.

Indeed, that is likely the reason. (Sorry, I should have read that more carefully: You really mentioned JCuda 10.1 and CUDA 10.2, and the difference is crucial here…)

That solved the problem. I was able to run my first „hello world“ program with JCUDA. Versions of CUDA and JCUDA have to match precisely.
Thank you so much for your patience with me. I learned a lot along the way about JAR files, DLLs etc… I think I should be thankful after all for this challenge.

One last question if you don’t mind. I am inspecting the JCuda documentation in http://www.jcuda.org/jcuda/doc/index.html. I can’t find the API spec for the package package jcuda.nvrtc in there. It appears to contain only documentation for the three packages jcuda, jcuda.driver and jcuda.runtime. I can inspect the code of course. But I just wonder why it is not showing in the documentation.

Oh dear. I have to admit that the website is not updated as actively as it had been before the world moved to GitHub and JCuda moved to Maven. Nowadays, people just add the dependency to their POM, and the IDE resolves the javadoc automatically.

Particularly, the JavaDocs are a bit tedious to maintain on the website. When I started all this (~12 years ago!), I just dumped the docs on the website via FTP, meaning that there is no infrastructure for autmatically uploading them.

So… that’s what I just did: The updated documentations are at

http://www.jcuda.org/jcuda/doc/index.html
http://www.jcuda.org/jcuda/jcublas/doc/index.html
http://www.jcuda.org/jcuda/jcufft/doc/index.html
http://www.jcuda.org/jcuda/jcusparse/doc/index.html
http://www.jcuda.org/jcuda/jcurand/doc/index.html
http://www.jcuda.org/jcuda/jcudnn/doc/index.html

(I know that for some CUDA-related websearches, these JavaDocs are the first thing that shows up in Google - so keeping them might not be the worst idea…)

However, note that for some libraries, the JavaDoc is essentially extracted from the header files - and … yeah, the header files do not contain any documentation in many cases. I actually once wrote some toolchain that reads the actual documentation from the CUDA documentation website (really parsing it, with the JerichoHTML parser), converts it to JavaDoc as far as reasonably possible, and inserts the result into my .java files. But in the meantime, NVIDIA changed the format and structure of their online documentation in an incompatible way, and started to use sophisticated MathML formatting or inlined images, so this toolchain would require a significant update and still could not convert many things to appropriate JavaDocs …

So „core JCuda“ should be documented reasonably and nearly completely. But for things like my pet peeve cudnnRNNBackwardData_v8, you should look at the original documentation, because the corresponding JavaDocs do not contain anything here :frowning: