Tracing Qt application with OpenGL ES 2.0

[akasilov]

Hi all,

I have a little demo application written in Qt 5.5 which uses OpenGL ES2. Qt is compiled with -opengl es2 flag. When I try to trace the application with apitrace I get the following error message: error: unavailable function glXGetProcAddressARB

It seems LD_PRELOAD does not work properly in this case. Maybe it is related to the fact that I am running on virtual machine? Can anybody help me with this issue?

Thank you!

Operating System: Ubuntu 14.04 running on VMware Player 12 OpenGL version string: 2.1 Mesa 10.5.9

[jrfonseca]

I think this is similar to

• https://github.com/apitrace/apitrace/issues/380
• https://github.com/anholt/libepoxy/issues/68#issuecomment-136723603

I think the only practical solution is to do what's explained in https://github.com/apitrace/apitrace/issues/380#issuecomment-136724464 , ie, modify apitrace to not intercept dlopen, but rather just dlsym.

I'll try to prototype this.

[akasilov]

By the way when I start apitrace with --api egl it works fine. But I suppose it must be possible to use --api gl to see OpenGL ES commands. Am I right?

Thanks.

[jrfonseca]

No.

Both -a egl and -a gl support desktop OpenGL, and OpenGL ES APIs.

-a egl means EGL API, where as -a gl means GLX/WGL/CGL API.

So the question is: is Qt using OpenGL ES with GLX, or with EGL. If the answer is EGL, then you should be using -a egl, no matter what.

[amonakov]

I think the only practical solution is to do what's explained in #380 (comment) , ie, modify apitrace to not intercept dlopen, but rather just dlsym.

Wouldn't LD_LIBRARY_PATH-based interposition actually be more practical? Even if it doesn't work today, I'd say it's worth to fix that if it's broken, instead of trying the way of intercepting dlsym — that way lies even more mess.

[jrfonseca]

Wouldn't LD_LIBRARY_PATH-based interposition actually be more practical?

Oh, yes, that too.

Even yesterday I was re-reading https://github.com/amonakov/on-wrapping/blob/master/interposers-discussion.asciidoc, but forgot to mention it.

I'd say it's worth to fix that if it's broken, instead of trying the way of intercepting dlsym — that way lies even more mess.

I suspect we'll need to support both.

For example, another reason for me to pursue dlopen -> dlsym interception is that NVIDIA Linux EGL drivers internally do dlsym(dlopen("libEGL.so.", 2), "NvGlEs2Init"); and egltrace.so intercepts dlopen returning its own handle, causing NVIDIA drivers to fail because egltrace.so doesn't have NvGlEs2Init.

I haven't tested but I'd expect LD_LIBRARY_PATH hooking would fail the exactly the same way, and it too would need to intercept dlsym to resolve the issue, so that dlsym of symbols not existing in the wrappers get redirected to the real library.

[akasilov]

Thanks. Now it is clear, I think the issue can be closed.