| Summary: | eglGetProcAddress("glMapBufferOES") doesn't work if the app links against both -lGL and -lGLESv2 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Neil Roberts <nroberts> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Standalone test case | ||
|
Description
Neil Roberts
2011-10-19 08:23:24 UTC
I cannot reproduce this. Do you still have the issue? Created attachment 53741 [details]
Standalone test case
I still have the issue but actually the situation is more complicated than I first thought. The problem is showing up in Cogl. Cogl is careful to dlopen either libGL or libGLESv2 to get the right GL API depending on an environment variable. All of the GL symbols it uses are queried using eglGetProcAddress or if that returns NULL it will use dlsym with the module handle of the GL library.
However, Cogl is also linking against Cairo which is linking against libGL. I'm guessing that means that Mesa is assuming we want to use the GL API maybe because it finds the _glapi_get_proc_address symbol from libGL first. That makes eglGetProcAddress return NULL for glMapBufferOES.
What is expected to happen when there are two libraries providing a GL API linked into a process? Ie, libGL and libGLESv2.
Here's a standalone test case simulating what Cogl does. If you link it with just -lEGL -lX11 -ldl then it works and draws a red triangle, but if you add in -lGL then it fails to find glMapBufferOES and gives up.
Does it help to configure mesa with --enable-shared-glapi and rebuild? The option is mandatory for GL and GLES interoperation. (In reply to comment #3) Yup, that fixes it. Thanks very much, I didn't know about that configure option. Sorry for the noise. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.