Hi, I’m trying to setup JCuda into my Ubuntu 10.04 (32 bits). I’ve managed to install the CUDA toolkit and the SDK. I’ve installed also the JCUDA libreries.
The problem is, when I try to execute a simple example, like the one proposed in http://forum.byte-welt.de/showthread.php?t=2972, the result is a unsatisfied link error with the typical result:
Error while loading native library with base name “JCudaRuntime”
Operating system name: Linux
Architecture : i386
Architecture bit size: 32
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 main.JCudaRuntimeTest.main(JCudaRuntimeTest.java:10)
So, I’ve debugged the code and I found this message in the stacktrace:
**/home/juancrug/workspace/jcuda/libJCudaRuntime-linux-x86.so: /home/juancrug/workspace/jcuda/libJCudaRuntime-linux-x86.so: undefined symbol: Pointer_buffer
**
It seems to me that the progam could find the library, but there’s another problem, I don’t know where, that prevents the library to be loaded.
I know this is a recurrent problem, I’ve tried almost I can do, but it still does not function.
Indeed, the problem occurs frequently, but there are always new, fascinating characteristics In this case: I have never seen (or even heard of) an „undefined symbol“ in an .so file.
But I chances are high that it is due to a wrong version: There currently are no binaries for 32bit Linux available - so there are no matching JCuda binaries for the latest CUDA version (3.2). As I just mentioned in another thread: I rarely have access to a Linux32 machine, but this weekend, I may have the chance to use one, and I’ll try to compile the required 32bit Linux binaries, so that I can upload them early next week.
Yes, I totally agree about the unsolved links in dyn libraries. Actually, since there are not binaries for 32 bits I’ve compiled them, but it doesn’t function. I don’t know, maybe I’m using the wrong versions. This is what I’ve used:
Java™ SE Runtime Environment (build 1.6.0_23-b05)
CUDA Drivers: developer driver 3.2 linux_32_260.19.26
At the moment, I’m still confused by the error message itself, so I’m not sure what of the environment that you described may be wrong.
So you compiled it from the sources (without error messages) and created the .SO files, and at runtime, it prints the error message? That’s strange.
The „Pointer_buffer“ should be used in the CommonJNI library, maybe there’s something wrong with static/dynamic linking or so? (Yes, I admit it: I’m spoiled by the „Compile“-Button in Visual Studio :o ). I’ll try to build the library ASAP. Unfortunately, I can not test the library itself, since the Linux32 machine that I can occasionally use has no CUDA-capable GPU. But maybe it helps.
Yes, I’ve compiled all the libraries, with some warnings but no errors. Acctually, the message is not printed in the console, I caught it by going into the variables of JCuda and looking into the Throwable object thrown by the exception.
If you want I can help you testing the libraries.
I have uploaded the latest version 0.3.2a, including the Linux binaries.
I was a little bit under pressure during the weekend, hopefully they work properly.
I’ve downloaded the current version 0.3.2a binaries. I tried to compile the JNI code, but I didn’t know how to use the common.mk file at the root of the source.
I look forward to a solution of this.
Thanks!
Regards!
Just to get this right: You downloaded the current Linux 32bit binaries, are are receiving the error message
“…undefined symbol: Pointer_buffer”
?
The common.mk is only referenced from the “main” makefile. Any adjustments of paths (e.g. to the JNI headers) should only be necessary in the ‘makefile’. Which output do you receive when stating ‘make’ ?
I compiled the Runtime test by the following console line, in the same directory as the files I’ve downloaded:
javac -cp „./jcuda0.3.2a.jar“ ./JCudaRuntimeTest.java
and I got the following error:
./JCudaRuntimeTest.java:3: package jcuda does not exist
import jcuda.*;
^
./JCudaRuntimeTest.java:4: package jcuda.runtime does not exist
import jcuda.runtime.*;
^
./JCudaRuntimeTest.java:14: cannot find symbol
symbol : class Pointer
location: class test.JCudaRuntimeTest
Pointer pointer = new Pointer();
^
./JCudaRuntimeTest.java:14: cannot find symbol
symbol : class Pointer
location: class test.JCudaRuntimeTest
Pointer pointer = new Pointer();
^
./JCudaRuntimeTest.java:16: cannot find symbol
symbol : variable JCuda
location: class test.JCudaRuntimeTest
JCuda.cudaMalloc(pointer, 4);
^
./JCudaRuntimeTest.java:20: cannot find symbol
symbol : variable JCuda
location: class test.JCudaRuntimeTest
JCuda.cudaFree(pointer);
^
6 errors
I also tried using the source code, within Eclipse IDE, and the error for the same file was:
Performing Sgemm with JCublas...
Error while loading native library with base name "JCublas"
Operating system name: Linux
Architecture : i386
Architecture bit size: 32
Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load native library
at jcuda.LibUtils.loadLibrary(LibUtils.java:79)
at jcuda.jcublas.JCublas.assertInit(JCublas.java:174)
at jcuda.jcublas.JCublas.cublasInit(JCublas.java:198)
at test.JCublasSample.sgemmJCublas(JCublasSample.java:70)
at test.JCublasSample.testSgemm(JCublasSample.java:55)
at test.JCublasSample.main(JCublasSample.java:31)
It could be helpful to know who’s who… JuanDavid, ursoouindio and Unregistered…
However… In the directory which contains
the .java source file and
the jcuda JAR files
the command line for compiling (on Linux) should be
javac -cp “.:jcuda0.3.2a.jar” JCudaRuntimeTest.java
And assuming that the .SO files are also contained in the same directory, the command for running should be
java -cp “.:jcuda0.3.2a.jar” JCudaRuntimeTest
I wonder why it complains about the missing JCublas library, because I assume that you have used the JCudaRuntimeTest from the FAQ, which should not contain any JCublas code. If you want to compile a JCublas example, you also have to add the JCublas JAR file to the classpath, but I recommend using only the simple example to see whether it’s working in general, and try out other libraries afterwards (preferably, from an IDE)
Sorry, Marco, it was me as Unregistered. Actually, my name is Marco too.
Just posted in a hurry and passed by that field.
Well, I just copy and pasted your javac call to compile and got the same 6 errors. The directory has all the .jar and .so files, together with the JCudaRuntimeTest.java (which I just copied from the faq page again).
And again, I posted the wrong error report inside Eclipse. It was for the JCublasSample.java file. For the JCudaRuntimeTest.java I get:
Error while loading native library with base name "JCudaRuntime"
Operating system name: Linux
Architecture : i386
Architecture bit size: 32
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 test.JCudaRuntimeTest.main(JCudaRuntimeTest.java:16)
I don’t really understand why it complains about not finding the JCuda classes: They are plainly contained in the JAR file… I’m not sure how this could be investigated further. One option could be to try using any other class from any other JAR file, but regardless of the outcome, it would not really lead to a solution (except for the point that itmay show that it’s not specifically related to the JCuda JARs ) …
Even more confusing is how you could start the Program (which lead to an UnsatisfiedLinkError) : So the compilation must have worked at least once, otherwise there would be no „JCudaRuntimeTest.class“ file!? The stack trace also contains
**at **test.JCudaRuntimeTest.main(JCudaRuntimeTest.java:16)
so it seems you put the main class into a package called ‚test‘?
The UnsatisfiedLinkError seems to be … „persistent“ on Linux32 - as I mentioned, I can not really test the native Linux32 libs, and they could only be compiled on an old machine without CUDA support. I can not guarantee that there is not something wrong with these, although I know that earlier versions had been working, and the process of creating them was not changed since then…
It would be good to know whether anybody got the Linux32 binaries running in any way…?
(I should probably try to get access to a Linux32 PC with CUDA, at the moment it’s hard for me to figure out what might be wrong there…)
I reviewd the steps and noticed that the command you posted above had the wrong jar name, the right one is: javac -cp “.:jcuda-0.3.2a.jar” JCudaRuntimeTest.java
It worded, but as I tried to run it, there is still the same error:
mamuller@Bennett:~/workspace/jcuda$ java -cp ".:jcuda-0.3.2a.jar" JCudaRuntimeTest
Error while loading native library with base name "JCudaRuntime"
Operating system name: Linux
Architecture : i386
Architecture bit size: 32
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:9)
I’m sorry I can’t help you more.
But I run other java projects here, so my problem shouldn’t be java-related. Maybe I need to do something else prior to run jcuda. Is there something else besides installing NVidia toolkit and drivers?
The problem is definitely related to the native library and not to Java in general. And usually the driver and toolkit should be enough (assuming that it’s the right version, namely CUDA 3.2, build 16).
But I still don’t know what might be the reason for the error. Did you add the paths to the CUDA Toolkit’s “bin” and “lib” directories to the LD_LIBRARY_PATH? You may want to try downloading the SDK and test one of the native CUDA examples, but … I have to assume that something went wrong during the compilation of the Linux32 libs, although at the moment I can not imagine what this should be. I’ll have another look at this as soon as I have the next chance to use the Linux32 system. Sorry for the inconveniences.
Just coming to my mind: In how far could this be related to the fact that the library is intended to be used on Ubuntu, but was compiled on SUSE? The Toolkit downloads are different ones for the different Linuxes, but I’m not so much familiar with Linux to know what exactly the difference is, or in how far it could influence a shared library…
I’m afraid I can’t help on this either, my knowledge on linux does not goes that far either. Ubuntu has come from Debian and Open Suse not, but I couldn’t tell at which point it will matter.
The PATH variable needs to include /usr/local/cuda/bin.
LD_LIBRARY_PATH needs to contain either /usr/local/cuda/lib or /usr/local/cuda/lib64 for 32- or 64-bit operating systems, respectively.
The typical way to place these values in your environment is with the following commands:
export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda/lib:$LD_LIBRARY_PATH
You might want to give it a try (and, if you want to test the CUDA installation in general, see if the native CUDA examples are running), but again: I can’t guarantee that the reason is not the JCuda binary in this case. Unfortunately, I don’t know anyone with a CUDA-capable Linux32 system who could help there, but maybe I’ll have the chance to again check this system which I used for compiling the libs, maybe I’ll find any hint…
So, I’m currently at a Linux PC, although it does not support CUDA, I tried to execute the example (it couldn’t do anything worse than simply crash… but it didn’t, anyhow). It also prints the UnsatisfiedLinkError message with the current binaries. The current binaries had been built with the 'makefile’s, so I tried building them again using the CMake files, and it still printed the error message. However, with
ldd -v libJCudaRuntime-linux-x86.lib
it printed „libcuda.so.1“ as a missing referenced library. I’m not sure if this should be installed atomatically with the CUDA driver, since I can’t install the driver here, of course. But when I extracted the libcuda.so file from the driver archive and simply copied it into the same directory as „libcuda.so.1“, it was possible to run the example program. (These „…so.1“ files should actually be „symbolic links“, as far as I know - you might have noticed that I’m not so familiar with Linux…) However, I couldn’t figure out what was wrong with the current binaries, since ‚ldd‘ did not report any missing library for those - maybe it was just some version issue…)
Long story short: I’ll upload the new binaries this evening, when I’m back at my „real“ PC, and chances are high that it will work with those. I’ll drop a note here as soon as they are uploaded.
Sorry for this hassle so far. (If anyone with a CUDA-capable Linux32 PC would like to contribute the Linux32 binaries for future versions: You’d be welcome )
In this case: I have never seen (or even heard of) an „undefined symbol“ in an .so file.
)