AnsweredAssumed Answered

Why does the OpenCL driver attempt to dlopen

Question asked by fesc2000 on Jan 16, 2015
Latest reply on Feb 5, 2015 by dipak



this is related to an issue i already reported a while ago and that came up in several other discussions (see Opengl interop / clCreateContextFromType segfault).


It is obvious then when i make use of OpenGL interoperability, the OpenCL library attempts a dlopen of From strace::

7913  open("/usr/lib/x86_64-linux-gnu/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

7913  open("/lib/x86_64-linux-gnu/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)



Whereas the application is linked against In my system (debian sid) these two ( and point to a different implementation (for whatever reason).

This eventually leads to an X error (or, if i remove, all ClGl sharing functions fail). I already filed a debian bug report, but the obvious question is:

- Why is fglrx trying to dlopen, instead of as it's supposed to do?

- And why is it trying to open it at all? It isn't necessary since the calling application must already be linked to libGL (the correct one), otherwise it couldn't provide the context information .. ?


My usual workaround after upgrading the fglrx package is to change the system's symlink of point to, but i always wonder why that should be an issue at all (and why no one else seems to have this problem)..