I have seen similar posts as this here, but none of those responses has helped my situation. I am running on a MacBook Pro with OS X 10.6.3. I can’t get any of the demo programs to run. I have installed the latest CUDA and JCUDA distributions. I set the java.library.path to the directory where the jnilib files are. I’ve tried with both “-d32” and “-d64” since there seems to be an issue with the fact that the mac is now running in 64-bit mode. (The -d32 allowed me to work around a 32- vs 64-bit issue I had recently with a completely unrelated java product.) No matter what demo program I run, the program executes up to the point where it needs to actually use some JCUDA functionality, then dies. For example, running “JCublasSample” and using “java -d32”, I see:
Creating input data…
Performing Sgemm with Java…
Performing Sgemm with JCublas…
Error while loading native library with base name “JCublas”
Operating system name: Mac OS X
Architecture : i386
Architecture bit size: 32
Exception in thread “main” java.lang.UnsatisfiedLinkError: Could not load native library
at jcuda.LibUtils.loadLibrary(LibUtils.java:74)
at jcuda.jcublas.JCublas.assertInit(JCublas.java:189)
at jcuda.jcublas.JCublas.cublasInit(JCublas.java:213)
at JCublasSample.sgemmJCublas(JCublasSample.java:64)
at JCublasSample.testSgemm(JCublasSample.java:49)
at JCublasSample.main(JCublasSample.java:25)
Unfortunately, there are currently no binaries available for 64bit Mac OS, since I currently have no possibility to compile and test on a MacOS machine. You may want to try compiling them from the source code. A makefile is included.
I assume that you have a 64 bit machine and the 64bit Java JDK/JVM installed, but the output says
Architecture : i386
Architecture bit size: 32
When you start with “java -d64”, does it then print a different Architecture information?
Hi,
Thanks for the quick response. I assumed the binaries were for 32 bit, that’s why I did -d32. When I run in 64-bit mode, I see the same error, but with the different architecture:
Creating input data…
Performing Sgemm with Java…
Performing Sgemm with JCublas…
Error while loading native library with base name “JCublas”
Operating system name: Mac OS X
Architecture : x86_64
Architecture bit size: 64
Exception in thread “main” java.lang.UnsatisfiedLinkError: Could not load native library
at jcuda.LibUtils.loadLibrary(LibUtils.java:74)
at jcuda.jcublas.JCublas.assertInit(JCublas.java:189)
at jcuda.jcublas.JCublas.cublasInit(JCublas.java:213)
at JCublasSample.sgemmJCublas(JCublasSample.java:64)
at JCublasSample.testSgemm(JCublasSample.java:49)
at JCublasSample.main(JCublasSample.java:25)
I’ll take a stab at recompiling everything on the mac as you suggest and see if that fixes it.
But doesn’t building a 64-bit version of jcuda require a 64-bit version of the base cuda as well? That seems to be available only for linux and Windows. Recompiling jcuda isn’t doing it, and this may be part of the problem.
I still think I ought to be able to get something working with the 32-bit cuda and 32-bit jcuda, as long as I specify -d32 on “java” and have the java.library.path set to the location of the 32-bit native jcuda jnilib files. But it just doesn’t seem to find the libraries. I tried re-packaging and running via javaws and a jnlp file, but the results are exactly the same.
Oh, I see, I was not aware of this: A quick websearch brought up this NVIDIA forum entry where they say that driver applications should work, and MacOS 64 bit runtime support will be added in the future … so, this does not help you so much right now as long as it is not possible to load the library from Java…
So you’re right, there’s probably no point in trying to compile it for 64 bit without a 64 bit CUDA.
I’m sorry that I can not give more specific help at the moment, but two points:
You might want to try putting the native JCuda library into the root directory of your project, just to make sure that it is really found and can be accessed, and to avoid searching for the reason for the error in the wrong place. Unfortunately, the error messages that are thrown when there are problems with the native library (in your case: “UnsatisfiedLinkError: Could not load native library”) seem to be specific for the Operating System, but not specific for the actual reason of the error: It does not say explicitly whether it simply does not find the library, or whether it can not be loaded due to a 32/64bit issue (It’s only a guess, but I’ve already seen some wierd and confusing error messages in this context…)
What version of the Java JDK/JVM do you have installed? I assume it’s a 64bit one, but although the -d32 flag really seems to affect the achitecture that is reported inside the JVM, it might be worth trying to install a 32bit JVM as well, and trying to start it from there, without the -d32 flag. Only a guess as well, but … hopefully if helps…