Just downloaded and linked version JCuda 0.9.2. I definitely have the JCudaDriver binary in my java.library.path as there is a not-found type error if I move the dll file. However, when the library is loaded here is an error. The other jCuda dlls do not give the same problem.
Exception in thread „main“ java.lang.UnsatisfiedLinkError: myPath.JCudaDriver-0.9.2-windows-x86_64.dll.dll: The specified procedure could not be found
My understanding is that this specified procedure is located in some missing dependency on another dll or there is a version clash.
I ran the dumpbin command with following result. I believe the nvcuda.dll referenced there is the problem,
Dump of file JCudaDriver-0.9.2-windows-x86_64.dll
File Type: DLL
Image has the following dependencies:
nvcuda.dll
ADVAPI32.dll
KERNEL32.dll
This could indeed be caused by a versioning problem.
Could you provide more information about your setup, e.g. whether it’s Windows 8/10, and more importantly: Which version of CUDA you have installed. Note that you will need CUDA 9.2. (and the matching driver) to use JCuda 0.9.2.
If there is still an older CUDA/driver version installed, this could explain the error that you see there.
So the version number seems to be fine. The libs are compiled on win 8.1, so there might be a hidden reason in that, but I cannot imagine that this is related to win10 in general (otherwise, people would likely have reported this issue earlier), but I can try to run a test on win10 in the next days and look for the ADVAPI DLL there - maybe this brings some insights…
“Good” and “bad” news: I just ran a test on a Win10 machine, and it reported the same error.
A quick analysis of the DLL revealed that it is looking for a function SystemFunction036 in the ADVAPI32.DLL. (Rant: It could have said this in the error message. By why should it? Nobody could use this information anyhow, except for googling it and finding that it is somehow related to random number generation: https://docs.microsoft.com/en-us/windows/desktop/api/ntsecapi/nf-ntsecapi-rtlgenrandom ).
Now, I have no idea where this dependency comes from and whether it could be avoided.
but…
when I tried to isolate the problem, I noticed that the problem does not exist … always. I tried to create a minimal test:
Create a directory like C:\JCudaTest and add the following files:
Suprisingly, when starting compileAndRun , it works for me!
(It would be great if you could confirm this).
However, even if it works, this doesn’t help much: It only raises the question of why it works from the command line, but not when started from within the IDE…
(Any ideas would be welcome here. I have never encountered this before, and am not sure how to properly investigate this…)
I followed you instructions above. Then I moved DOS window to the C:\JCudaTest directory and called the bat file. The compile step executed to create the class file. However, in the java-execution step the dll was not found. It looks like the dll has the wrong name… missing the x86_64. Looks like this command line runs in a 32 bit windows.
C:\JCudaTest>compileAndRun
C:\JCudaTest>echo Compiling...
Compiling...
C:\JCudaTest>javac -cp ".;jcuda-0.9.2.jar;jcuda-natives-0.9.2-windows-x86_64.jar" JNvrtcVectorAdd.java
C:\JCudaTest>PAUSE
Press any key to continue . . .
C:\JCudaTest>echo Running...
Running...
C:\JCudaTest>java -cp ".;jcuda-0.9.2.jar;jcuda-natives-0.9.2-windows-x86_64.jar" JNvrtcVectorAdd
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error while loading native library "JCudaRuntime-0.9.2-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-0.9.2-windows-x86 in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at jcuda.LibUtils.loadLibrary(LibUtils.java:143)
at jcuda.runtime.JCuda.initialize(JCuda.java:422)
at jcuda.runtime.JCuda.<clinit>(JCuda.java:406)
at jcuda.driver.JCudaDriver.<clinit>(JCudaDriver.java:293)
at JNvrtcVectorAdd.main(JNvrtcVectorAdd.java:69)
Stack trace from the attempt to load the library as a resource:
java.io.IOException: No resource found with name '/lib/JCudaRuntime-0.9.2-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:422)
at jcuda.runtime.JCuda.<clinit>(JCuda.java:406)
at jcuda.driver.JCudaDriver.<clinit>(JCudaDriver.java:293)
at JNvrtcVectorAdd.main(JNvrtcVectorAdd.java:69)
---(end of nested stack traces)---
at jcuda.LibUtils.loadLibrary(LibUtils.java:193)
at jcuda.runtime.JCuda.initialize(JCuda.java:422)
at jcuda.runtime.JCuda.<clinit>(JCuda.java:406)
at jcuda.driver.JCudaDriver.<clinit>(JCudaDriver.java:293)
at JNvrtcVectorAdd.main(JNvrtcVectorAdd.java:69)
This is really odd, indeed. Did you just start the standard command line (basically „cmd“)? Or is this some odd „backward compatibility“ mode?
I’ll try to check both cases when I’m back at the Win10 PC (namely the case where it works and the one where it doesn’t work) to see which architecture is detected there.
EDIT: Well, no, this does not make sense: If it detected the wrong architecture, it wouldn’t even come to the point where it could not find a certain procedure. However, I’ll try to investigate further what might cause the procedure to not be found in the first place…
Well, during a quick test, I could not reproduce the error any more: Now it worked from the command line and from the console. I’ll try again later today, probably after removing the temp-files and with a fresh project - that’s the only reasonable approach as long as I have no idea what might have caused the error originally…
As long as you use 64-bit commands, while in cmd.exe, you will be using 64-bit command line tools; however, if you run a 32-bit command that command will still run, but it will be in 32-bit mode.
By the way, I have 3 versions of the ADVAPI32.dll on my system under C:\Windows\WinSxS and they apparently have different contents. After copy/paste to another folder, only one of them can be loaded in Java with System.loadLibrary(xx.dll) . The working one is not the first in my windows PATH.
Sorry, but perhaps another source of incompatibility for different users of Windows. See here. ADVAPI32.dll
A guess: The observed behavior (i.e. the fact that it reports a 32bit system) can simply be caused by a 32bit Java Version being installed.
When you do a java -version at the command line, what does it print? It should involve some statement about being “64 bit”. If this is not the case, you could either adjust your PATH to not point to the 32bit JRE, or adjust the compileAndRun.bat above to explicitly point to the 64bit version:
"C:\Program Files\Java\jdkXYZ\bin\java" -cp ...
(i.e. not “Program Files (x86)”)
More broadly speaking, I’ll try to figure out where the dependency to ADVAPI comes from. It’s unlikely, but maybe it can simply be omitted by some magic linker flags or so…
When I first ran the test, it reported the “procedure not found” error.
Shame on me: I’m not sure whether that was before or after I installed CUDA.
At some point (after isolating the test case), it started to work, without the error message
This was definitelyafter I installed CUDA
Now I’m at a point where I cannot reproduce the error. That’s not ideal…
An aside: You seem to assume that the error was caused by the ADVAPI DLL. Since there are many websearch results talking about “similar problems”, this is not unlikely, but is there any specific technical reason for this assumption? It does not say which procedure is not found, though…
Could it be that you installed a Graphics Card Driver from NVIDIA after you installed CUDA?
It might be that some graphics card driver overwrites some files (that are relevant for the operation of CUDA) with older versions. I’m primarily thinking about the nvcuda.dll, which is unversioned (!) and, as far as I know, also installed during a driver installation.
A quick attempt here could be to re-install CUDA (which contains the driver that is “guaranteed” to be the right one), but again, that’s only a guess (because otherwise, I’m running out of ideas of how to tackle this…)
EDIT: The reason of why I think that this might be the issue is mainly that I think that I observed the error only before installing CUDA (although I’m not entirely sure). A test that I could do here would be to intentionally try and install a different (older) driver version to see whether I can reproduce the error afterwards…
Indeed, I have both 32 and 64 versions of java and running the 32 version in the command line, but I check the IDE is using the 64 bit version using this code line.
println(„java bit type =“ + System.getProperty(„sun.arch.data.model“))
I changed the bat file to point to the 64 bit versions of javac and java. Now it reports an error with the correct 64 bit architecture and again related to the JCudaDriver. The original error is reproduced.
C:\JCudaTest>"C:\Program Files\Java\jdk1.8.0_111\bin\java" -cp ".;jcuda-0.9.2.jar;jcuda-natives-0.9.2-windows-x86_64.jar" JNvrtcVectorAdd
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error while loading native library "JCudaDriver-0.9.2-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 JCudaDriver-0.9.2-windows-x86_64 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.driver.JCudaDriver.<clinit>(JCudaDriver.java:296)
at JNvrtcVectorAdd.main(JNvrtcVectorAdd.java:69)
Stack trace from the attempt to load the library as a resource:
java.lang.UnsatisfiedLinkError: C:\Users\my user name\AppData\Local\Temp\JCudaDriver-0.9.2-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:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
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.driver.JCudaDriver.<clinit>(JCudaDriver.java:296)
at JNvrtcVectorAdd.main(JNvrtcVectorAdd.java:69)
---(end of nested stack traces)---
at jcuda.LibUtils.loadLibrary(LibUtils.java:193)
at jcuda.driver.JCudaDriver.<clinit>(JCudaDriver.java:296)
at JNvrtcVectorAdd.main(JNvrtcVectorAdd.java:69)
Did you see the last post about the possible driver update?
Of course, I know, that’s a weak advice: „Just re-install it“ ("…and try to turn it off an on again" ) but the symptoms could be explained by a wrong driver version, at least generally, and I don’t have any other idea right now…
(In doubt, I can look up the version of nvcuda.dll that I currently have, when I’m back at the Win10 PC)
Great to hear that. I was running out of ideas, and afraid that it might be necessary to create a dedicated „Windows 10“ version of JCuda - that would have been annoying. So … once more the „turn it off and on again“-approach solved it
) but the symptoms could be explained by a wrong driver version, at least generally, and I don’t have any other idea right now…
The command line test worked and the IDE worked. I seem to remember updating the driver recently.