Xorg, AIGLX and gallium3d drivers

[Peter Hjalmarsson]

Hi all.

The gallium3d drivers (at least nouveau and radeon) seems to utilize 
_glapi_get_proc_address.
On an ordinary system Xorg will not care about this symbol during start 
of AIGLX due to lazy bindings, and when you run an application yourself 
this will resolv the symbol back to mesa and mesa/src/mesa/glapi/
glapi_getproc.c where this symbol is marked PUBLIC.

However if your mesa is linked with -z,now or you try to start Xorg with 
LD_BIND_NOW=1 then Xorg will fail to resolv _glapi_get_proc_address and 
be unable to load *_dri.so.

This seems to be because xserver/glx/glapi.c does not mark the symbol as 
PUBLIC.

Observe that this seems so long only to be a problem with mesa gallium3d 
drivers, mesa classic drivers seems to works as they should.

Now to my questions:
1. Are my conclusions correct?

2. If AIGLX somehow is to utilize a function depending on 
_glapi_get_proc_address, will this function fail or will it be able to 
look the symbol up with the help of libGL.so (i.e. is this broken for 
other use-cases then -z,now/LD_BIND_OW)?

3. Is this patch against xserver correct (can confirm that it fixes/
workarounds the issue here)?


diff --git a/glx/glapi.c b/glx/glapi.c
index d6a568e..df65970 100644
--- a/glx/glapi.c
+++ b/glx/glapi.c
@@ -892,7 +892,7 @@ _glapi_get_proc_offset(const char *funcName)
  * in the name of static functions, try generating a new API entrypoint 
on
  * the fly with assembly language.
  */
-_glapi_proc
+PUBLIC _glapi_proc
 _glapi_get_proc_address(const char *funcName)
 {
    struct _glapi_function * entry;