cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

fesc2000
Adept I

PLEASE fix Linux opengl/opencl interop

Hi,

I have posted this issue years (?) ago and even opened a ticket at the debian fglrx packet maintainer.

Whatever the cause, it is STILL not fixed:

When using opengl/opencl interop, the opencl library apparently dlopens libGL.so, whereas my application is linked against libGL.so.1.

But /usr/lib/x86_64-linux-gnu/libGL.so and libGL.so.1 are different binaries.

This eventually leads to a crash (X error).

Every time i do an upgrade of packages, i have to manually link libGL.so to libGL.so.1 so that my application works again.

PLEASE AMD: You are not supposed to dlopen("libGL.so"), use dlopen("libGL.so.1")!

By the way, why do you have to open libGL again at all? If i have an application does gl/cl interop than it has to be linked to the correct libGL anyway. Otherwise it couldn't provide the context information ...

Regards,

Felix.

0 Likes
4 Replies

Dear Felix,

I can assure you that AMD OCL is dlOpening "libGL.so.1". It is required to gain access to a private CL-GL interface exported from GL.

Tzachi

0 Likes

Hi Tzachi,

Hmm, but i know that it once did. Maybe i'm still using an old version (fglrx-driver (1:14.9+ga14.201-2)).

Two weeks ago i did an update on debian sid, and the error again, and i had to fix it by linking libGL.so to libGL.so.1.

I'll probably try the official libraries from the AMD site. Sorry for the fuss if it's fixed.

- Felix.

0 Likes
nibal
Challenger

fesc2000 wrote:

Hi,

I have posted this issue years (?) ago and even opened a ticket at the debian fglrx packet maintainer.

Whatever the cause, it is STILL not fixed:

When using opengl/opencl interop, the opencl library apparently dlopens libGL.so, whereas my application is linked against libGL.so.1.

But /usr/lib/x86_64-linux-gnu/libGL.so and libGL.so.1 are different binaries.

This eventually leads to a crash (X error).

Every time i do an upgrade of packages, i have to manually link libGL.so to libGL.so.1 so that my application works again.

PLEASE AMD: You are not supposed to dlopen("libGL.so"), use dlopen("libGL.so.1")!

By the way, why do you have to open libGL again at all? If i have an application does gl/cl interop than it has to be linked to the correct libGL anyway. Otherwise it couldn't provide the context information ...

Regards,

Felix.

LigGL from linux calls some raster function, that ubuntu installation doesn't provide. It is broken, and a well known libGL bug. I use the fgrlx libGL.so for all my needs. How do you figure that using libGL.so.1 will fix your library paths? libGL.so is just a link. It sounds that you are asking amd to hardwire the library path in their applications. Doesn't sound too good 😞

0 Likes

Well, i'm using debian together with the fglrx package.

In this situation libGL.so and libGL.so.1 is a different binary (in /usr/lib/x86_64-linux-gnu), for what reason ever. I'm linking my application with -lGL, and ldd says it links against libGL.so.1.

This works fine with OpenCL as long as i don't use interop. Then i see (with dltrace/strace) that at some point libGL.so gets loaded, and the application eventually crashes with an X error (probably because the GL context information is incompatible).

If i move the original libGL.so away and link it to libGL.so.1 everything works fine, up to the next time mesa/glx gets an update and i have to redo this procedure.

This has been the case for years now.

I addressed this to the Debian package maintainer, and the usual answer is that applications should dlopen "so.x" instead of "so".

I'm not the only one with this issue, see  Bug 601 – Never dlopen libGL.so, but rather libGL.so.1

- Felix

0 Likes