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

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90311

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
improved/fixed.

 - __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.

Cheers,
Emil

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

"""

-- 
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>