(In reply to comment #0)
> This is tested on Debian Sid with libegl1-mesa 7.10-4.
> 
> EGL drivers in /usr/lib/egl import some symbols from libGL.so. However, the
> driver shared objects does not appear to explicitly link against libGL:
> 
> % ldd /usr/lib/egl/egl_dri2.so
>         libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xb76e1000)
>         libX11.so.6 => /usr/lib/libX11.so.6 (0xb75c1000)
>         libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0xb75bd000)
>         libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0 (0xb75b8000)
>         libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb75b1000)
>         libxcb-shape.so.0 => /usr/lib/libxcb-shape.so.0 (0xb75ae000)
>         libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7595000)
>         libudev.so.0 => /lib/libudev.so.0 (0xb7585000)
>         librt.so.1 => /lib/librt.so.1 (0xb757c000)
>         libEGL.so.1 => /usr/lib/libEGL.so.1 (0xb756d000)
>         libc.so.6 => /lib/libc.so.6 (0xb7428000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb7424000)
>         libXau.so.6 => /usr/lib/libXau.so.6 (0xb7420000)
>         libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb741b000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0xb7402000)
>         /lib/ld-linux.so.2 (0xb7700000)
> 
> If/When EGL is not already exported in the global symbols list of the running
> process, the process aborts at run-time as follows:
> 
> ./vlc: symbol lookup error: /usr/lib/egl/egl_dri2.so: undefined symbol:
> _glapi_get_proc_address
> 
> This can occur because there is absolutely no warranty that libGL.so is loaded
> with dlopen(RTLD_GLOBAL). Indeed VLC loads its plugins with dlopen(RTLD_LOCAL),
> including the EGL plugin. In this case, the run-time linker will load the EGL
> plugin's underlying library also with RTLD_LOCAL.
> 
> 
> Note: We already had a similar problem in Mesa 7.8, whereby drivers were not
> linked against libEGL.so correctly. This seems fixed in Mesa 7.10. Please
> consider linking with -z,defs to eliminate this class of bugs.

Because egl_dri2.so can also work with libGLESv2, and at build time we can not decide GL or GLES to link against. The problem here is undefined symbol which is defined in libGL.so or libglapi.so. And if -enable-share-glapi option is enabled at build time, libGL.so will also depend on libglapi.so, which has the only _glapi_get_proc_address symbol, in this case we just need to link egl_dri2.so against libglapi.so. But if this option is not enabled, libGL.so will have its own version of _glapi_get_proc_address, and we still don't know which library to link against, libGL or libglapi. So the final solution of this problem depends on when the '-enable-share-glapi' option will be enabled by default in mesa. ;)

It's enabled by default now.