Custom Compile: Unsatisfied Link

[GoogleCodeExporter]

Hi,

I tried to compile Aparapi by myself with my latest fix enabled. The ant 
command works great, the jni binary is produced and it runs on the machine it 
was created. However, when changing over to another machine, I get the problem 
that Java tells me that the aparapi_x86_64.dll cannot be loaded, as some 
procedure cannot be found:

Exception in thread "main" java.lang.UnsatisfiedLinkError: 
D:\lib\aparapi_x86_64.dll: Die angegebene Prozedur wurde nicht gefunden

Now I am wondering whether anyone of you has experienced the same behaviour and 
can tell me what I am doing wrong during compiling. This is definitely not an 
issue of Aparapi but probably my own fault ...

Thanks,
Matthias

Original issue reported on code.google.com by matthias.klass@gmail.com on 9 Jul 2013 at 8:51

[GoogleCodeExporter]

Really really strange. I found a Google Groups thread from last year. The guy 
had exactly the same problem as I have. What happened is you gave him a patch 
to resolve this problem, which lay in the usage of a 
#clEnqueueMarkerWithWaitList method. The patch resolved this behaviour by 
checking for the OpenCL version and using the method only if it is available.

When I just removed that "IF" and hard coded it to use OpenCL 1.1, I do not get 
the UnsatisfiedLinkError. Now I am trying to figure out which OpenCL version I 
really have ...

Original comment by matthias.klass@gmail.com on 9 Jul 2013 at 10:01

[GoogleCodeExporter]

Hm the source code actually is right, as far as I can tell. The CL_VERSION_1_2 
attribute is correct, the clEnqueueMarkerWithWaitList function was also added 
in 1.2.

I suppose the issue is the underlying NVIDIA OpenCL implementation. However, 
when running exactly the same compiled code on my home computer, I don't 
experience that issue, even though I also got an NVIDIA GPU at home.

... this doesn't make much sense, but at least it works ...

Original comment by matthias.klass@gmail.com on 9 Jul 2013 at 12:09

[GoogleCodeExporter]

Looks like you have narrowed it down. So the problem is if you build on a 
machine which has 1.2 compatible OpenCL SDK and then try to run on a 1.1 
compatible runtime. 

Actually I thought we had already retracted the code using 
clEnqueueMarkerWithWaitList and added the compile flag 
   -DCL_USE_DEPRECATED_OPENCL_1_1_APIS

Hmm, so I note that the builds do set the above flag, but I think that 
Aparapi.cpp should indeed be changed.  

This method 

int enqueueMarker(cl_command_queue commandQueue, cl_event* firstEvent) {
#ifdef CL_VERSION_1_2
   return clEnqueueMarkerWithWaitList(commandQueue, 0, NULL, firstEvent);
#else
   // this was deprecated in 1.1
   return clEnqueueMarker(commandQueue, firstEvent);
#endif
}

Should be replaced with

int enqueueMarker(cl_command_queue commandQueue, cl_event* firstEvent) {
   // this was deprecated in 1.1 so compile with  -DCL_USE_DEPRECATED_OPENCL_1_1_APIS
   return clEnqueueMarker(commandQueue, firstEvent);
}

Then, I think a build against 1.2 SDK *should* work even on platforms with 1.1 
runtimes.

BTW I think this is a regression. I thought I had fixed this once before.

If this works for you then I will commit this change to the trunk.

Gary

Original comment by frost.g...@gmail.com on 9 Jul 2013 at 2:05

[GoogleCodeExporter]

Hi,

yes, this is exactly what I did do make it work.

Thanks,
Matthias

Original comment by matthias.klass@gmail.com on 9 Jul 2013 at 2:06

[GoogleCodeExporter]

OK I just committed this change (see r#1326).  Thanks for hanging in there and 
reporting this. 

Gary

Original comment by frost.g...@gmail.com on 9 Jul 2013 at 2:11

• Changed state: Fixed