On 06/16/2016 06:36 AM, Mike Gorchak wrote: > Hi, > >> You're supposed to get at these functions with eglGetProcAddress() and > such > > A'm afraid EGL v1.4 spec forbids obtaining core functions through > eglGetProcAddress(), they should be visible at dynamic linker level.
Unless you have the EGL_KHR_get_all_proc_addresses extension, which I believe Mesa has. :) > Anyway, thanks! > > > On Wed, Jun 15, 2016 at 3:06 PM, Ilia Mirkin <imir...@alum.mit.edu > <mailto:imir...@alum.mit.edu>> wrote: > > On Wed, Jun 15, 2016 at 2:55 PM, Mike Gorchak > <mike.gorchak....@gmail.com <mailto:mike.gorchak....@gmail.com>> wrote: > > Hi, > > > > hm, could you check "cat ./src/mapi/es2api/glapi_mapi_tmp.h | grep > > glFramebufferParameteri" ? > > > > I can see void APIENTRY gl_dispatch_stub_888(GLenum target, GLenum > pname, > > GLint param); instead of glFramebufferParameteri there. > > > > Also objdump -x for GLES 2.0 API shows absence of > glFramebufferParameteri() > > function as well. Only GLES 3.0 functions are present. > > I'm not up on all the latest, but are those supposed to be there? This > just means that they're not exposed symbols in libGLESv2.so, which > afaik is right. It's definitely right for libGL.so. You're supposed to > get at these functions with eglGetProcAddress() and such. However > perhaps the policy for libGLESv2.so is supposed to be different? Ian > will know for sure. > > -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev