Absolute library path in OpenCL ICD is getting in the way

[maxzhen]

Today, we have absolute library path in our OpenCL ICD entry. This is getting in the way when I was trying to debug my app. It'll always load the released version of the libs, not the one in my workspace even when I set LD_LIBRARY_PATH using run.sh correctly.

If I change the entry to just specify "libxilinxopencl.so", it will work since the LD_LIBRARY_PATH now gets control of where the lib is loaded from.

So, we probably need to revisit what we put into the ICD.

[stsoe]

One problem with relative path is that it requires LD_LIBRARY_PATH being set. With absolute path, user should be able to run any OpenCL application without setting environment first. I don't know of a good solution to override the ICD loader when debugging.

[maxzhen]

So do we recommend not to install the package and use OpenCL's ICD when you need to debug the libraries?

[stsoe]

Lacking a better suggestion, I recommend modifying the ICD loader text file as we did this morning if and only if you need to debug. Regardless of installation or not, you will have a problem is there is an old version of XRT installed but you want to debug with your own local version.

[maxzhen]

I'm wondering if it's appropriate to add a check in run.sh for absolute path setting in ICD and warn user that you might not be doing what you think you are?

[maxzhen]

In run.sh, we can run ldd against host.exe to see if it's directly linked against libOpenCL.so. If yes, then we can check if we have absolute path in ICD. If yes, then we can warn user about this.

[keryell]

I think we have to focus on having the normal case be simple for the normal user.
A user wanting to debug XRT will be probably knowledgeable to handle debugging with the ICD, changing /etc/OpenCL/vendors/xilinx.icd, play with https://github.com/intel/opencl-intercept-layer or whatever.
So what about closing this issue and considering the current state as a normal behaviour?