(In reply to comment #0)
> I tried to verify the mesa support for EGL with full OpenGL API on my ARM
> platform with Ubuntu 10.10. But the OpenGL state tracker st_GL.so cannot be
> loaded successfully when call eglCreateContext. After export
> EGL_LOG_LEVEL=debug, I got following error message.
> 
> libEGL debug: searching for st module GL
> libEGL debug: /usr/lib/egl/st_GL.so: undefined symbol: _glapi_tls_Context
How did you configure mesa?  It looks like src/mapi/glapi is compiled without GLX_USE_TLS, but the rest of mesa is compiled with it defined.
> libEGL debug: searching for st module (null)
> libEGL debug: /usr/lib/egl/st_.so: cannot open shared object file: No such file
> or directoy
> iibEGL warning: unable to load st_GL.so

The mesa is configured as below, "--enable-glx-tls" is there.

./configure --prefix=/usr --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --build=arm-linux-gnueabi --with-driver=dri --with-dri-drivers=swrast mga r128 r200 r300 r600 radeon savage tdfx --with-dri-driverdir=/usr/lib/dri --with-egl-displays=x11 drm --enable-glx-tls --enable-gallium-swrast --enable-gallium-nouveau --enable-gallium-radeon --enable-gallium-r600 --with-state-trackers=egl,glx,dri,vega --enable-gles-overlay --enable-gles1 --enable-gles2 --enable-driglx-direct --disable-glu --disable-glut --disable-glw CFLAGS=-Wall -g -O2

So, when built with --enable-glx-tls, libGL contains a definition for _glapi_tls_Context, but neither libEGL nor any of the egl_{dri2,gallium,glx}.so loaders define this symbol.

I'll look into this.

(In reply to comment #3)
> So, when built with --enable-glx-tls, libGL contains a definition for
> _glapi_tls_Context, but neither libEGL nor any of the egl_{dri2,gallium,glx}.so
> loaders define this symbol.

Yes, I think this is the problem.

> 
> I'll look into this.

Thanks.

Created attachment 40975 [details] [review]
Link st_GL to libGL

Does this patch help?

_glapi_tls_Context is defined in libGL.so, libGLESv1_CM.so, and libGLESv2.so.  But since st_GL.so can support all 3 APIs, it cannot link to any of them at compile time.  If the patch works, I will look into if there is any dlopen trick that may help the situation.

It looks like st_GL has been built with tls enabled, but the EGL loader has not been(In reply to comment #5)
> Created an attachment (id=40975) [details]
> Link st_GL to libGL
> 
> Does this patch help?
> 
> _glapi_tls_Context is defined in libGL.so, libGLESv1_CM.so, and libGLESv2.so. 
> But since st_GL.so can support all 3 APIs, it cannot link to any of them at
> compile time.  If the patch works, I will look into if there is any dlopen
> trick that may help the situation.

I don't quite see how you can actually use the OpenGL API in the EGL without having a libGL built for EGL use like libGLES* are.  As far as I can tell, none of the GL entry points are actually exported for you to link with, and eglGetProcAddress shouldn't let you query for core GL functions (I suspect that mesa's eglGetProcAddress will, but that's not guaranteed by the spec).  I must be missing something.

If mesa built such a libGL.so that could define the _glapi_tls_Context symbol in the same way that libGLES*.so currently do.

(In reply to comment #5)
> Created an attachment (id=40975) [details]
> Link st_GL to libGL
> 
> Does this patch help?
> 
> _glapi_tls_Context is defined in libGL.so, libGLESv1_CM.so, and libGLESv2.so. 
> But since st_GL.so can support all 3 APIs, it cannot link to any of them at
> compile time.  If the patch works, I will look into if there is any dlopen
> trick that may help the situation.

I just tried this patch. EGL+OpenGL API can basically work now, although still some remapping index failures.

(In reply to comment #6)
> It looks like st_GL has been built with tls enabled, but the EGL loader has not
> been(In reply to comment #5)
Not exactly.  The missing symbol is in libGL*.so.  st_GL.so should link to one
of them.  The problem is that it does not know which one.  So it relies on the
application linking to the right one.  This sure will break if the app loads
libGL*.so without RTLD_GLOBAL, or loads after the creation of the EGLContext.

A sane fix is to move _glapi_tls_Context (and other _glapi_* symbols) to
another library, say libglapi.so, where all libGL*.so can link to.  It is then
safe for st_GL.so to link to libGL.so.  But that might create other issues that
I don't see now.
> > Created an attachment (id=40975) [details] [details]
> > Link st_GL to libGL
> > 
> > Does this patch help?
> > 
> > _glapi_tls_Context is defined in libGL.so, libGLESv1_CM.so, and libGLESv2.so. 
> > But since st_GL.so can support all 3 APIs, it cannot link to any of them at
> > compile time.  If the patch works, I will look into if there is any dlopen
> > trick that may help the situation.
> 
> I don't quite see how you can actually use the OpenGL API in the EGL without
> having a libGL built for EGL use like libGLES* are.  As far as I can tell, none
> of the GL entry points are actually exported for you to link with, and
> eglGetProcAddress shouldn't let you query for core GL functions (I suspect that
> mesa's eglGetProcAddress will, but that's not guaranteed by the spec).  I must
> be missing something.
dlopen and dlsym?
> If mesa built such a libGL.so that could define the _glapi_tls_Context symbol
> in the same way that libGLES*.so currently do.

(In reply to comment #7)
> (In reply to comment #5)
> > Created an attachment (id=40975) [details] [details]
> > Link st_GL to libGL
> > 
> > Does this patch help?
> > 
> > _glapi_tls_Context is defined in libGL.so, libGLESv1_CM.so, and libGLESv2.so. 
> > But since st_GL.so can support all 3 APIs, it cannot link to any of them at
> > compile time.  If the patch works, I will look into if there is any dlopen
> > trick that may help the situation.
> 
> I just tried this patch. EGL+OpenGL API can basically work now, although still
> some remapping index failures.
I've made a commit to do some more work when loading st_GL.so.  It should help for this specific issue, but it does not solve the real problem mentioned in last comment.

This problem has been fixed in latest mesa driver with fix for GL and GLES interop.