[Mesa-dev] [Bug 90311] Fail to build libglx with clang at linking stage

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jul 22 15:40:55 PDT 2015


Julien Isorce <julien.isorce at gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |emil.l.velikov at gmail.com

--- Comment #3 from Julien Isorce <julien.isorce at gmail.com> ---
Emil I am not gonna try your solution soon so I copy/past your comment from
mailing list here in case someone else finds this bug and wants to go ahead:

So as mentioned previously glx (libGL) should interact with the
dispatch directly, rather than have any knowledge in the
implementation detail (which lies in mesa).

src/glx/indirect_glx.c is a nice example, where __glXNewIndirectAPI
(autogenerated from
mapi/glapi/gen/glX_proto_send.py) is used to create the dispatch table
and then set it with _glapi_set_dispatch().

AppleDRI uses similar approach
_glapi_create_table_from_handle(generated from
mapi/glapi/gen/gl_gentable.py), but there are things that could be

 - __ogl_framework_api does not need to be over a thousand entries
long. There are six overrides + __ogl_framework_api->Scissor used.
So tweaking the generator to directly produce __applegl_api and(?) a
slimmed down __ogl_framework_api sounds like a good idea to me.

Further on one could also:
 - Drop the multiple forward declarations of __ogl_framework_api.
 - Wrap/implement appledri around __GLXDRI(display|screen) shoving
storing things like dl_handle, thus allowing things to be torn down on
exit. Namely I'm suggesting to cleanup and test Jon's earlier work.
 - apple_glapi_set_dispatch is called "too late" - at
applegl_bind_context. According to the docs/spec one should be able to
fetch the function pointers without any context let alone a currently
bound one.
 - As a follow up from the above struct
glx_context_vtable::get_proc_address could be nuked, making the struct
fit nicely into 32/64 byte cache :-)

Obviously if you can find an alternative way (but not as hacky as this
one) that'll be great.


P.S. Why is there no appledriproto package, similar to xf86driproto
and friends ? Having appledri{,str}.h duplicated seems fragile and


You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150722/78077ba6/attachment.html>

More information about the mesa-dev mailing list