Bug 90311 - Fail to build libglx with clang at linking stage
Summary: Fail to build libglx with clang at linking stage
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
Depends on:
Reported: 2015-05-05 08:02 UTC by Julien Isorce
Modified: 2018-08-23 23:29 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

applegl: Provide requirements of _SET_DrawBuffers (1.78 KB, text/plain)
2015-05-05 08:02 UTC, Julien Isorce

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Isorce 2015-05-05 08:02:36 UTC
Created attachment 115539 [details]
applegl: Provide requirements of _SET_DrawBuffers

I can confirm the problem still exists.

Patch is used in MacPorts: https://trac.macports.org/browser/trunk/dports/x11/mesa/files/5003-applegl-Provide-requirements-of-_SET_DrawBuffers.patch
Comment 1 Julien Isorce 2015-05-05 21:08:55 UTC
The exact error is:

CCLD     libGL.la
clang: warning: argument unused during compilation: '-pthread'
Undefined symbols for architecture x86_64:
  "_driDispatchRemapTable", referenced from:
      _apple_glapi_set_dispatch in libglx.a(apple_glapi.o)
      _apple_glapi_oglfw_viewport_scissor in libglx.a(apple_glapi.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
Comment 2 Jon Turney 2015-05-11 17:16:45 UTC
I don't remember all the details, but when I wrote "XXX: There has to be a better way fixing this.", I think my concern was that
perhaps this indicates that the partitioning of functionality into whatever it is that provides _SET_DrawBuffers isn't quite right.

That said, I have no problem with this patch being applied as is, as it's pretty non-invasive and clearly an improvement over the current situation.
Comment 3 Julien Isorce 2015-07-22 22:40:55 UTC
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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.