Archives Discussions

[fesc2000]

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.

[dipak]

Hi Felix,

I too found the same. When I used strace for SimpleGL sample, I found (see below) calls to both libraries: libGL.so.1 and libGL.so. It initially loads libGL.so.1 and then tries to load libGL.so. [FYI. In my case, the SimpleGL ran successfully]

66  open("/home/guest/AMDAPPSDK-3.0-0-Beta/lib/x86_64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

67  open("/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = 3

3136  open("/home/guest/AMDAPPSDK-3.0-0-Beta/lib/x86_64/libGL.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

3137  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 16

…

3141  open("/lib64/libGL.so", O_RDONLY|O_CLOEXEC) = 16

When I checked the dependency chain of /lib64/libGL.so on Redhat7 (64bit), I found following:

/lib64/libGL.so -> /usr/lib64/libGL.so.1

/usr/lib64/libGL.so.1 -> /usr/lib64/libGL.so.1.2

/usr/lib64/libGL.so.1.2 -> /usr/lib64/fglrx/fglrx-libGL.so.1.2

I don't know how libraries are loaded by runtime/driver. I guess, I need to check with runtime/driver team for clarification. Will get back to you later.

Regards,