UnsatisfiedLinkError: could not load native library

[Sebastien]

Hello,

I am unfortunately adding up to the long list of the UnsatisfiedLinkError... I spent a long time trying many of the suggestions that have been posted so far and I still could not get the JCudaRuntimeTest minimalistic java program to run, always getting the same message error when launching it:

Error while loading native library with base name "JCudaRuntime"
Operating system name: Windows XP
Architecture : amd64
Architecture bit size: 64
Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load native library
at jcuda.LibUtils.loadLibrary(LibUtils.java:79)
at jcuda.runtime.JCuda.assertInit(JCuda.java:225)
at jcuda.runtime.JCuda.cudaMalloc(JCuda.java:1775)
at JCudaRuntimeTest.main(JCudaRuntimeTest.java:8)

I am using the amd64 version 4.1 of the JCuda libraries, my NVIDIA computing toolkit match this version (cudart64_41_21 matches the dll dependence of JcudaRuntime.dll). My JDK is 1.7.0_02-b13 - windows 64 bit version. My %path% environment variable is pointing to the folder where the JCuda libraries are stored as well as to C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.1\bin. I tried to copy all the JCuda dlls (as well as all the dlls I could find in the NVidia SDK) to the calling java program with no success. It is difficult to guess what is going wrong in the dll loading... anybody managed to use JCuda with this same configuration? Any hint?

Regards,
Sébastien

[Marco13]

Hello

You obviously ruled out most of the "usual" reasons for this error. According to your description, I can't see (or even imagine) a possible reason for the error. Two rather helpless guesses:
- Could you run the examples from the SDK?
- Are you sure that there is no other, older CUDA DLL installed (maybe from an old toolkit) ?

I'll try to run another test on a Win64 machine tomorrow, with the JDK 1.7. I think until now I tested it only with 1.6, but that should not make a difference, but it's in fact the only difference that I can see between your configuration and the one where I'm actually compiling and testing the Win64 libs...

bye
Marco

Hello Marco,

Could you run the examples from the SDK? --> yes, all the examples I tried compiled and runned (except the DirectX ones because I do not have the DirectX SDK)

- Are you sure that there is no other, older CUDA DLL installed (maybe from an old toolkit)? --> 100% sure, it is the first CUDA SDK I am installing on this machine.

I'll try to run another test on a Win64 machine tomorrow, with the JDK 1.7. I think until now I tested it only with 1.6 --> I use 1.7 because I tried to upgrade it to solve the issue (from previous comments). I had 1.6 before and the result was the same.

It's in fact the only difference that I can see between your configuration and the one where I'm actually compiling and testing the Win64 libs... --> bad news for me, JCuda looks like a jewel to me since I want to do CUDA dev with simple binding to ImageJ.

If I cannot get it to work I could just try to setup a simple JNI bridged C program that calls a standard Nvidia CUDA file compiled with MSVC++ 2008 and Nvidia rules. Is there much more to JCuda? Is there a way to have a more verbose tracing of the dll loading failure?

Best regards,
Sébastien

[Marco13]

Hello

I just tested it again, with the current files from the website, on Windows 7 (64bit), and here it works. But I noticed that the error message that you posted said that you are using Windows XP. I can not test it on an WinXP 64bit machine at the moment. I think that the DLLs should work on all Win64 versions, but since this is a difference that at least might have an influence, I can not be 100% sure...

Maybe more importantly:

Zitat von Unregistriert

I want to do CUDA dev with simple binding to ImageJ.

Did you use the "ImageJ Quick Start package" from the website? Note that this package (as mentioned on the website) is slightly out-dated and unversioned for the sake of simplicity (I'll update it as soon as possible). In any case, you should also use the JARs from the latest download package. This also refers to your question

Is there a way to have a more verbose tracing of the dll loading failure?

The latest version should print a little bit more info. For example, I just removed one DLL and thus provoked an error, and it should print something like

Error while loading native library "JCudaRuntime-windows-x86_64" with base name "JCudaRuntime"
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/JCudaRuntime-windows-x86_64.dll'
	at jcuda.LibUtils.loadLibraryResource(LibUtils.java:151)
	at jcuda.LibUtils.loadLibrary(LibUtils.java:83)
	at jcuda.runtime.JCuda.initialize(JCuda.java:303)
	at jcuda.runtime.JCuda.<clinit>(JCuda.java:290)
	at JCusparseSample.main(JCusparseSample.java:31)
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError: no JCudaRuntime-windows-x86_64 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:94)
	at jcuda.runtime.JCuda.initialize(JCuda.java:303)
	at jcuda.runtime.JCuda.<clinit>(JCuda.java:290)
	at JCusparseSample.main(JCusparseSample.java:31)

Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load the native library
	at jcuda.LibUtils.loadLibrary(LibUtils.java:129)
	at jcuda.runtime.JCuda.initialize(JCuda.java:303)
	at jcuda.runtime.JCuda.<clinit>(JCuda.java:290)
	at JCusparseSample.main(JCusparseSample.java:31)

The part that says "no JCudaRuntime-windows-x86_64 in java.library.path" might contain the valuable information in this case.
So are you sure that you are also using the latest version of the JARs?

If I cannot get it to work I could just try to setup a simple JNI bridged C program that calls a standard Nvidia CUDA file compiled with MSVC++ 2008 and Nvidia rules. Is there much more to JCuda?

In fact, JCuda basically consists of the low-level bindings - a 1:1 mapping of the API. And if you only want to perform a single, complex CUDA operation, it might be justifiable to create an own JNI interface, which contains only one special-purpose native method like 'doTheComplexComputationWithCUDA' - but of course the intention of JCuda is to avoid this, and to provide the original flexibility of CUDA for Java. Hopefully we'll still get it running somehow.

bye
Marco

Hello Marco,

I started from scratch and this time copied the dll in the CUDA toolkit directory to make sure that they were visible... and I got the minimalist example to work! Now I will try to setup an ImageJ plugin with JCuda.

Yes you are right having a direct access to the CUDA functions in JAVA is more flexible but still the hardcore development will always be in C (for the kernels) and as such a generic JNI bridge that passes an ImageJ image (or a stack) pointer and parameters to a CUDA-C function (used as a building template) might be useful too (I used something similar for Matlab in the past). I never used JNI and my JAVA knowledge is at the moment very low - would you by any chance know where to find such template? Thanks a million for the great job and for your help and sorry for erroneously adding up to the linkerror list!

Cheers,
Seb

[Marco13]

Well, good to hear that - although copying any JCuda DLLs to the NVIDIA directory should NOT be necessary. If there is "only" the problem that the DLLs can not be found, this can usually be solved by simply putting the DLLs into the root directory of the project, or, alternatively, specifying the path where they are located using the "java.library.path". But at least you can run first tests now.

Yes, the fact that the kernels always have to be developed in C (and that a C-Compiler is required) could be considered as a drawback. In contrast to that: In OpenCL, you can simply define the Kernel source code as a String, and use the built-in compiler of OpenCL. I think that one of the major assets of NVIDIA and CUDA is that they have powerful runtime libraries (CUBLAS, CUFFT, etc).

By the way: There is also a runtime library called NPP ( http://developer.nvidia.com/npp ) which contains thousands (!) of image processing routines. I'm currently preparing a VERY early alpha release of "JNpp". JNpp again just offers the low-level access to the NPP functions as-they-are. But I intended to create a set of utility classes that offer the functionality of (J)Npp in a more Java-friendly way. This will be challenging and I'm not even 100% sure if I will get it done at all, but I'll try. Recently, I have been asking for support (in this thread (german), maybe some google translation helps to get the message). The most challenging parts of these utility-classes may probably be independent of ImageJ, but having some background knowledge in ImageJ would certainly be helpful...

EDIT: Concerning the "template" you have been asking for: I'm not entirely sure what you mean. Since the class (ImagePlus or stack) and the parameters will be highly specific for the problem, there will hardly be a one-fits-all solution. There are several approaches for simplifying the connection between Java and DLLs (like JNA or BridJ, or maybe Swig) but I haven't seen any of them applied to CUDA.

bye
Marco

Hello,

I could also compile and get the JCuda enabled ImageJ plugin to work but it requires to change the jcudaUtils file for the newest one (jcudaUtils-0.0.4.jar), I think you mentioned something about a future update of this package.

Thanks!
Seb

[Marco13]

The main reason why the "ImageJ Quick Start Package" requires an update is because it still contains the old (unversioned) JAR files. I hope that I can do this update soon, and maybe create one or more examples showing how JNpp may be used together with ImageJ.

Admittedly, I have not done anything with ImageJ except for creating the example a while ago (and I basically wrote down what I did to get it running - that's the "Tutorial" now ), but I think that CUDA, and especially NPP, may be very well suited for image processing in general, so having a closer look at this should definitely be worthwhile.

Hello again,

I will have a look at NPP, I am really curious to see if advanced image processing functions (advanced image segmentation for instance) have been implemented... I thought only filters and basic image processing functions were implemented so far in such libraries but the scene is moving fast... regarding the template I mentioned I would be happy to have it setup for standard 8-bit stacks - the only objects that should be passed to the C-CUDA function should be a pointer to the stack and 3 parameters (width, height and number of slices of the stack). From this most Image processing could be implemented. JNI is an option but JNA and swig both look good, thanks for pointing them out!

Good luck with your work, I will definitely keep an eye on the progress and get back to you if I start implementing advanced CUDA enabled ImageJ plugins!

Regards,
Seb

[Marco13]

The "Image Segmentation" you mentioned may be covered with the functions that are also mentioned at the NPP main page: The "NPP graphcut primitive". Although I'll have to read more about this - until now, I "blindly" created the bindings for NPP, an just started testing and experimenting further...

the only objects that should be passed to the C-CUDA function should be a pointer to the stack and 3 parameters (width, height and number of slices of the stack).

Of course, it may have the advantage of simpler usage and less method call overhead, but the disadvantage of reduced flexibility. One could consider to develop and experiment with the Java bindings, and for the "final release version" (when only the fixed functionality is required) creating such a C function that summarizes the full (specific) functionality. However, there are several options, and certainly it's possible to find a feasible solution.