Hi!
I’ve seen only binaries for 32bit Linux. How can I use JOCL on 64bit VM on Linux?
Best regards
Hello,
Currently, there are only pre-built binaries for 32bit Linux. It should, however, be possible to compile the native library on 64bit Linux using the makefile that is contained in the source code package.
If someone provided the 64bit Linux libraries, I could upload them to the website 
bye
Marco
Thanks. It’s working 
I can provide the binaries, it’s not a problem…Will take care of it tomorrow.
Great If you send me the binaries via mail, I’ll upload them ASAP - this will certainly be helpful for others.
I’m not sure if its my fault but I think I’ll dig up this one cause I’m still unable to use my app on linux.
I’ve just switched my notebook to one with 64bit linux support yet still I cannot run my app.
Here’s some more terminal output:
$ ls
JOCL-linux-x86_64.so lib Zefir.jar
$ ls lib/
appframework-1.0.3.jar JOCL-0.1.4-beta1.jar swing-worker-1.1.jar
$ java -jar Zefir.jar
Error while loading native library "JOCL-linux-x86_64" with base name "JOCL"
Operating system name: Linux
Architecture : amd64
Architecture bit size: 64
Stack trace:
java.lang.UnsatisfiedLinkError: no JOCL-linux-x86_64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1047)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:72)
at org.jocl.CL.<clinit>(CL.java:47)
at zefir.ZefirMath.createContext(ZefirMath.java:59)
at zefir.ZefirMath.init(ZefirMath.java:50)
at zefir.ZefirView$thread.run(ZefirView.java:919)
at java.lang.Thread.run(Thread.java:636)
Exception in thread "Thread-2" java.lang.UnsatisfiedLinkError: Could not load the native library
at org.jocl.LibUtils.loadLibrary(LibUtils.java:83)
at org.jocl.CL.<clinit>(CL.java:47)
at zefir.ZefirMath.createContext(ZefirMath.java:59)
at zefir.ZefirMath.init(ZefirMath.java:50)
at zefir.ZefirView$thread.run(ZefirView.java:919)
at java.lang.Thread.run(Thread.java:636)
So tell me what am I doing wrong or think what have you done wrong with instructions. Btw this doesn’t work in Netbeans too and google search shows some other guyz having problems with this too.
If you refer to the UnsatisfiedLinkError in general: Yes, this is extremely common for all JNI applications. This is due to the many possible reasons for this error, and the fact that it is usually not very specific.
This thread contains some general information about this error - although it refers to JCuda, it may be helpful if you have not already seen it.
In this specific case: You are only giving the Zefir.jar as an argument - but no classpath at all. Did you pack the JOCL JAR into the Zefir JAR?
You may also want to try the JAR from the Maven Repo: http://repo1.maven.org/maven2/org/jocl/jocl/0.1.4c/jocl-0.1.4c.jar . (I also wanted to upload this JAR to the website, but this is pending again for several reasons…). This JAR contains the native libraries for Win32/64, Linux64 and MacOS64, and they are loaded directly from the JAR file - this might help to reduce the number of possible reasons for this error.
After checking out the info you gave me I have combined the libraries and my app into singe jar file including the jocl with libraries inside and thats the output:
$ java -jar Zefir-combined.jar
Error while loading native library "JOCL-linux-x86_64" with base name "JOCL"
Operating system name: Linux
Architecture : amd64
Architecture bit size: 64
Stack trace from the attempt to load the library as a resource:
java.lang.UnsatisfiedLinkError: /tmp/jocl-8778844958503608975.tmp: libOpenCL.so.1: can not open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1750)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1646)
at java.lang.Runtime.load0(Runtime.java:787)
at java.lang.System.load(System.java:1022)
at org.jocl.LibUtils.loadLibraryResource(LibUtils.java:159)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:83)
at org.jocl.CL.<clinit>(CL.java:47)
at zefir.ZefirMath.createContext(ZefirMath.java:59)
at zefir.ZefirMath.init(ZefirMath.java:50)
at zefir.ZefirView$thread.run(ZefirView.java:919)
at java.lang.Thread.run(Thread.java:636)
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError: no JOCL-linux-x86_64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1047)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:93)
at org.jocl.CL.<clinit>(CL.java:47)
at zefir.ZefirMath.createContext(ZefirMath.java:59)
at zefir.ZefirMath.init(ZefirMath.java:50)
at zefir.ZefirView$thread.run(ZefirView.java:919)
at java.lang.Thread.run(Thread.java:636)
Exception in thread "Thread-2" java.lang.UnsatisfiedLinkError: Could not load the native library
at org.jocl.LibUtils.loadLibrary(LibUtils.java:117)
at org.jocl.CL.<clinit>(CL.java:47)
at zefir.ZefirMath.createContext(ZefirMath.java:59)
at zefir.ZefirMath.init(ZefirMath.java:50)
at zefir.ZefirView$thread.run(ZefirView.java:919)
at java.lang.Thread.run(Thread.java:636)
I have ati stream sdk installed however I don’t have that missing file and renaming/moving/linking the libOpenCL.so to .so.1 doesn’t change this problem. I hope you will be able to think something about this in future releases and make including those libraries as idiot-proof as in windows 
Woh… sorrry, my question
**Did you pack the JOCL JAR into the Zefir JAR? **
should not suggest that you should to this - I was just wondering how he can find the CL class when you only give the Zefir.jar as an argument, but do not specify the location of the JOCL JAR in the classpath. How should he know that one specific library (named “JOCL-0.1.4-beta1.jar”, which is in the subdirectory named “lib”) should be used?
Actually, the usage should be equal on Windows and Linux. Did you try specifying the path to the native library in the LD_LIBRARY_PATH?
I know that it does include jocl jar file from lib - Netbeans creates it so it can load those classes from jar files in lib directory. The only problem is with the so file that isn’t loaded from launch directory. My second thought is that you have named the files libJOCL-linux-x86_64.so while erros are about missing JOCL-linux-x86_64.so. After renaming the file (cutting off “lib” from filename) it had been loaded with errors that i posted in my previous reply.
Indeed, you’re right, this „lib“ prefix might cause problems when trying to load the library from the JAR. I’ll have to check this as soon as possible.
But in any case, it should be possible to get it running with the version that is currently available on the website, when the library is not contained in the JAR, but in a directory that is visible for the JVM.
I’m not sure how NetBeans assembles the JAR-in-JAR-Packages, and how this might affect the loading Mechanisms of the native library. Therefore, another attempt:
- Create Zefir.jar without the JOCL JAR
- put the Zefir.JAR and the JOCL JAR into one directory
- Put the native lib (libJOCL-linux-x86_64.so) into the same directory
- In this directory, execute
java -cp ".;JOCL-0.1.4-beta1.jar" -jar Zefir.jar
It should be possible to get this running in the end
From the start I’ve been creating Zefir.jar without including the library jar files( i did this only to check it out)
having all files both in launch dir with Zefir.jar and lib sub-dir i did as you said and its still the same error as the first one:
$ java -cp ".;JOCL-0.1.4-beta1.jar" -jar Zefir.jar
Error while loading native library "JOCL-linux-x86_64" with base name "JOCL"
Operating system name: Linux
Architecture : amd64
Architecture bit size: 64
Stack trace:
java.lang.UnsatisfiedLinkError: no JOCL-linux-x86_64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1047)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:72)
at org.jocl.CL.<clinit>(CL.java:47)
at zefir.ZefirMath.createContext(ZefirMath.java:59)
at zefir.ZefirMath.init(ZefirMath.java:50)
at zefir.ZefirView$thread.run(ZefirView.java:919)
at java.lang.Thread.run(Thread.java:636)
Exception in thread "Thread-2" java.lang.UnsatisfiedLinkError: Could not load the native library
at org.jocl.LibUtils.loadLibrary(LibUtils.java:83)
at org.jocl.CL.<clinit>(CL.java:47)
at zefir.ZefirMath.createContext(ZefirMath.java:59)
at zefir.ZefirMath.init(ZefirMath.java:50)
at zefir.ZefirView$thread.run(ZefirView.java:919)
at java.lang.Thread.run(Thread.java:636)
I wish it would work out of box but it doesn’t and i coulnd’t pass this error on both i386(my last machine) and amd64 kernels.
On i386 i thought I was the one to make sth wrong with compiling from sources however here’s exactly the same case.
I’m really running out of ideas. The UnsatisfiedLinkError is spookily common, but in most cases it works at least for a basic test when everything is put into one directory. Unfortunately, the error message is not very specific, but since it explicitly complains about that, you may try
java -Djava.library.path=/path/to/library**** -cp “.;JOCL-0.1.4-beta1.jar” -jar Zefir.jar
Although this should not be necessary when everyhing is in the same directory.
In any case, I’ll try to create an updated version of the JAR which contains the native libraries (taking into account the “lib”-prefix for the library name on linux) as soon as possible. There’s still hope that this way the error can be avoided in this case (and maybe even the number of threads about UnsatisfiedLinkErrors may be reduced in general).
Sorry for the inconveniences so far…
It’s not a problem with loading the jocl jar but with .so library. If i remove jar i have nullpointers to jocl classes so we can assume linking jar is not a problem. On the second thought if I understand it clearly I think you should check if the “base name” of the compiled version is really “JOCL” not something slightly different that would cause the problems.
Anyway no need to be sorry, there’s no rush and I’ve just checked it by the way to see if its working out of box in amd64 ubuntu and if it’ll cause some problems with memory in linux too.
The app did its job and I’m grateful to you for help. This time I’ve just wanted to support you with this info.
I’m not sure if I got this wrong, but the
-Djava.library.path=/path/to/library
refers to the path of the native library - namely, the .SO file. You could even query this Variable (the java.library.path) inside the program to see whether it contains the path where the .SO file is located.
I’m just wondering if this may in any way be related to the Linux version … but I think it should not. Let’s see if the updated version (with the natives inside the JAR, and the fix for the “lib” prefix) works, I’ll try to build it and notify you as soon as possible.
Hello,
I have uploaded a new snapshot: Version 0.1.4d snapshot.
It should now no longer show the error message that you mentioned in this post: The JAR contains the native libraries, and the bug (indeed, it was a bug) of the missing “lib”-prefix for the native libraries on Linux and Mac should be fixed now. So whenever it finds the JAR, it should also be able to find and load the native lib.
Unfortunately, my possibilities for testing this on non-Windows-Systems are rather limited. It would be great to know whether it works, so it can be put into a release (and finally, the Maven repo can be linked on the homepage, by the way…)
bye
Good, now i’ve got the error about missing „libOpenCL.so.1“ Where should it be installed? I’ve got the ati stream sdk installed from deb package distributed by stream community guy
Anyway thats one step forward with fixing that bug.
Hm - I’m not at a Linux machine at the moment, and rarely have access to one in general. Even more imporant: I’m not a linux expert, and usually only use it to compile the library…
But these “…so.1” files seem to be so-called “symbolic links” which somehow have to point to the “real” library location. The path for the real OpenCL lib should be something like
/opt/ati-stream-sdk-v2.3/lib/x86_64/libOpenCL.so
But I’m not sure how to properly manage these “symbolic links”. The only thing that I could see from threads like this one is, that they may be created with a command like
ln -s **symbolicLinkName ** realLibraryName
but I don’t know how to properly apply this to the OpenCL lib - e.g. I’m not sure where the symbolic link has to be located. Does the error message contain information about the path where these links are expected?
BTW: Did you also add the stream SDK path to the LD_LIBRARY_PATH? It should be something like
export LD_LIBRARY_PATH=/opt/ati-stream-sdk-v2.3/lib/x86_64/
int the “bashrc” config file.
Maybe some Linux guru reads this and can give us some helpful pointers…? Otherwise, I’ll have to search the web a little bit more, maybe I can find out how to get it running…