[Mesa-dev] Xorg, AIGLX and gallium3d drivers
xake at rymdraket.net
Mon Sep 27 04:29:23 PDT 2010
The gallium3d drivers (at least nouveau and radeon) seems to utilize
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
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
@@ -892,7 +892,7 @@ _glapi_get_proc_offset(const char *funcName)
* in the name of static functions, try generating a new API entrypoint
* the fly with assembly language.
_glapi_get_proc_address(const char *funcName)
struct _glapi_function * entry;
More information about the mesa-dev