[Mesa-dev] [PATCH] glx: Don't uselessly dlopen libGL within libGL

[Adam Jackson]

On Thu, 2014-05-29 at 15:10 -0700, Ian Romanick wrote:

> That code was originally added by:
> 
> commit 061a3fe34051327fba418cc99599ecff0016ee15
> Author: Michel Dänzer <michel at daenzer.net>
> Date:   Mon Aug 14 15:53:37 2006 +0000
> 
>     Bug #7169: Attempt to make libGL symbols visible to drivers.
>     
>     Some applications end up dlopening libGL without RTLD_GLOBAL, so the libGL
>     symbols referenced by the driver can't be unresolved when libGL dlopens it.
>     This attempts to make the libGL symbols visible to the driver by dlopening
>     libGL (again) with RTLD_GLOBAL before dlopening the driver and dlclosing
>     the obtained handle afterwards.
> 
> So... I think that's not how dlopen always works.  For other reasons, I
> don't think the DRI drivers directly access symbols from libGL, so this
> may be safe anyway.  I'd want to see it tested, though.

Tested this with a cut-down version of glxdemo.c:

http://people.freedesktop.org/~ajax/dlopen-glxdemo.c

And with the dlopen of libGL removed indeed it doesn't DTRT:

dmt:~% ./glxdemo 
libGL error: dlopen /usr/lib64/dri/i965_dri.so failed (/usr/lib64/dri/i965_dri.so: undefined symbol: _glapi_tls_Dispatch)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i965

Which I guess makes sense.  The RTLD_LOCAL open of libGL means neither
libGL nor its dependencies are made visible to other loaded objects, and
libGL happens to be the only thing linked against libglapi.  I think
that's just a bug, the drivers should link against glapi as well.

However just linking the drivers against glapi wouldn't necessarily mean
we could eliminate the self-dlopen from libGL, because it would break
the case of app doing dlopen(new libGL, LAZY) with an old driver.  Is
this a thing we actually care about?  Can we not?  In RHEL6 we have a
package of Mesa 7.11 that just emits the DRI1 drivers for compatibility
since we've rebased our real Mesa, but I'd be entirely happy to update
mesa-dri1-drivers to be properly linked if we pulled this change into a
future RHEL6 update.

- ajax