AnsweredAssumed Answered

Why does the OpenCL driver attempt to dlopen libGL.so?

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

Hi,

 

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 libGL.so. From strace::

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

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

...

 

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

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

- Why is fglrx trying to dlopen libGL.so, instead of libGL.so.1 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 libGL.so point to libGL.so.1, but i always wonder why that should be an issue at all (and why no one else seems to have this problem)..

 

Thanks,

 

Felix.

Outcomes