[Mesa-dev] Understanding GLX_INDIRECT_RENDERING (libOSMesa fails to link due to gl_dispatch_stub*)

[Chia-I Wu]

On Tue, Jun 7, 2011 at 12:25 PM, Jeremy Huddleston <jeremyhu at apple.com> wrote:
> I'm having trouble understanding why GLX_INDIRECT_RENDERING changes what is built into glapi.  I assumed that glapi was agnostic to the actual implementation, so why does glapi care about GLX_INDIRECT_RENDERING?
> I'm trying to build mesa with support for (only) indirect rendering on darwin.  libGL (src/glx, not src/glx/apple) builds fine, but libOSMesa fails to build due to missing symbols.  I'm guessing osmesa.c needs the same GLX_INDIRECT_RENDERING hunk as in src/gallium/targets/libgl-xlib/xlib.c (6678f597e7c9ba784c9af0c86cfc6821558bcaa7) and src/mesa/drivers/x11/glxapi.c (888429360a30090b9ecd17bfd160a88141195235), but I'd like to know *why* this is happening, so I have a better understanding of how to make an indirect+applegl mesa.
In indirect rendering, glGenTextures and glGenTexturesEXT, for
example, use different opcodes.  However, those functions are assigned
the same dispatch offset in glapi.  If glapi defines both of them,
they will be dispatched to the same function, using the same opcode.

As a workaround, when GLX_INDIRECT_RENDERING is defined, glapi no
longer defines glGenTexturesEXT.  Those link to libglapi.a are
supposed to define the function.  Since libglapi.a still references
glGenTexturesEXT (in _glapi_get_proc_address), not defining the
function will result in link errors.  Same to other functions.

> Thanks,
> Jeremy
>
> /bin/sh ../../../../bin/mklib -o OSMesa -linker 'g++' -ldflags '' \
>                -major 7 -minor 11 -patch 0 \
>                -install ../../../../lib -cplusplus  \
>                -id /opt/X11/lib/libOSMesa.7.dylib \
>                -L../../../../lib -lGL osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mapi/glapi/libglapi.a ../../../../src/glsl/libglsl.a
> mklib: Making Darwin shared library:  libOSMesa.7.11.dylib
> Undefined symbols for architecture x86_64:
>  "_gl_dispatch_stub_356", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_357", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_358", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_359", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_361", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_362", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_363", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_364", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_365", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
>  "_gl_dispatch_stub_366", referenced from:
>      _static_functions in libglapi.a(glapi_getproc.o)
> ld: symbol(s) not found for architecture x86_64
>
>



-- 
olv at LunarG.com