[QUOTE=Fancy]It compiles and run fine now. Excellent.
...
/home/mschorn/Downloads/Temp/JOCL/src/main/native/JOCL.cpp: In function ‘jint Java_org_jocl_CL_clEnqueueNativeKernelNative(JNIEnv*, jclass, jobject, jobject, jobject, jlong, jint, jobjectArray, jobjectArray, jint, jobjectArray, jobject)’:
/home/mschorn/Downloads/Temp/JOCL/src/main/native/JOCL.cpp:6112:20: warning: converting to non-pointer type ‘jint {aka int}’ from NULL [-Wconversion-null]
return NULL;
^
/home/mschorn/Downloads/Temp/JOCL/src/main/native/JOCL.cpp:6123:20: warning: converting to non-pointer type ‘jint {aka int}’ from NULL [-Wconversion-null]
return NULL;
^
[ 22%] Building CXX object CMakeFiles/JOCL_0_2_0-linux-x86_64.dir/src/main/native/Logger.cpp.o
...
[/quote]
That’s surprising. Due to Murphy’s laws, I thought I had overlooked exactly one place that caused a warning. Now it has been two. Fixed 
Have you ever thought about placing JOCLSample as integration test to the maven lifecycle?
Sure. There’s a sticky note on my keyboard: „JOCL Unit-Tests“ (this already raised some eyebrows elsewhere…). Of course, I have a set of tests, but they are not written as (J)Unit-Tests right now. Some basic tests could trivially be converted to Unit-Tests (e.g. the JOCLSample). But others (as the GL interoperability) not. I’ll try to do the cleanup/merge of my local project (with local SVN repo) and the Maven/Git version today, maybe I can also start converting the Integration tests into Unit-Tests then.
Yes, cmake is a big simplification. And not every build tool can have the elegancy of maven.
Oh, the irony Sure, just having to add a simple is elegant. But this „elegance“ comes from a mix of constraining the user, and from the fact that creating a binary from the „usual“ target Language (Java) is trivial.
Yes, basically it calls dlopen/dlsym.
According to this document, libOpenCL.so.1.0.0 is the realname, libOpenCL.so.1 is the soname and libOpenCL.so should be the linker name. ldconfig set up only the soname, not the linker name.
Another sentence from the document:
First I thought one could simply use this pattern internally - basically, call
if (dlopen("libX.so")) return fine;
if (dlopen("libX.so.1")) return fine;
but this does not make sense: It should always try to load the latest available OpenCL implementation library. To my understanding, when you install an OpenCL 2.0 library, you might end up with a „libOpenCL.so.2“ (or „2.0“ or „2.0.0“ or whatever…), and JOCL should try to pick this one (and not any hard-coded „.so.1“ version).
I guess setting up the soname with ldconfig (to point to the latest linker-name-library) is technically not the worst solution here. But of course, people will run into this, and complain about an „UnsatisfiedLinkError“ when the link „libOpenCL.so → libOpenCL.so.1“ is not set up. (And sometimes when it IS set up - see java - Cannot load native libOpenCL.so library from Maven resource - Stack Overflow …)
- it IS a hassle, but at least, CMake comes pretty close to being a real cross-platform build tool. I mean, look at the files that it generates (the makefiles, or the vcxproj files). This certainly is tremendously complex (and then there are still things that HAVE to be platform- and compiler dependent, after all).