Bug 41999 - eglGetProcAddress("glMapBufferOES") doesn't work if the app links against both -lGL and -lGLESv2
Summary: eglGetProcAddress("glMapBufferOES") doesn't work if the app links against bot...
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-19 08:23 UTC by Neil Roberts
Modified: 2011-11-30 06:17 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
Standalone test case (10.39 KB, text/x-csrc)
2011-11-21 07:40 UTC, Neil Roberts 		Details
View All

Description Neil Roberts 2011-10-19 08:23:24 UTC 
When using a GLES2 context, the GL_OES_mapbuffer extension is advertised but if you actually try to call it ends up in generic_nop and throws a warning.
Comment 1 Chia-I Wu 2011-11-05 00:58:22 UTC 
I cannot reproduce this.  Do you still have the issue?
Comment 2 Neil Roberts 2011-11-21 07:40:50 UTC 
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.
Comment 3 Chia-I Wu 2011-11-29 22:32:44 UTC 
Does it help to configure mesa with --enable-shared-glapi and rebuild?  The option is mandatory for GL and GLES interoperation.
Comment 4 Neil Roberts 2011-11-30 06:17:44 UTC 
(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.