[Mesa-dev] build failure: _mesa_BindAttribLocation vs _mesa_lookup_shader_program_err , GLuint vs GLhandleARB

[Emil Velikov]

On 25/05/14 02:12, Jeremy Huddleston Sequoia wrote:
> I'm getting this build failure:
> 
> main/shader_query.cpp:49:7: error: no matching function for call to '_mesa_lookup_shader_program_err'
>       _mesa_lookup_shader_program_err(ctx, program, "glBindAttribLocation");
>       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../src/mesa/main/shaderobj.h:81:1: note: candidate function not viable: cannot convert argument of incomplete type 'GLhandleARB'
>       (aka 'void *') to 'GLuint' (aka 'unsigned int')
> _mesa_lookup_shader_program_err(struct gl_context *ctx, GLuint name,
> ^
> 
> _mesa_lookup_shader_program_err is defined as:
> 
> extern struct gl_shader_program *
> _mesa_lookup_shader_program_err(struct gl_context *ctx, GLuint name,
>                                 const char *caller);
> 
> 
> but it is being passed a GLhandleARB rather than an GLuint by _mesa_BindAttribLocation:
> 
> void GLAPIENTRY
> _mesa_BindAttribLocation(GLhandleARB program, GLhandleARB index,
>                             const GLcharARB *name)
> {
>    GET_CURRENT_CONTEXT(ctx);
> 
>    struct gl_shader_program *const shProg =
>       _mesa_lookup_shader_program_err(ctx, program, "glBindAttribLocation");
> ...
> 
> This seems like an old bug that is just now coming to light.  The main reason nobody else seems to have hit this in a while is that on most platforms, GLhandleARB and GLuint are both 'unsigned integer', so the compiler happily goes back and forth between the two, but on darwin, GLhandleARB is a void * and thus cannot be implicitly cast to an unsigned int:
> 
> #ifdef __APPLE__
> typedef void *GLhandleARB;
> #else
> typedef unsigned int GLhandleARB;
> #endif
> 
> How should we address this?  I'd really really really prefer to not have to put a bunch of casts everywhere, and I'm ok breaking binary compatibility on darwin in fixing this.
> 
Hi Jeremy,

IIRC there was another location where the above typedef gave us the finger.
Not entirety sure what the conclusion on the topic was and I believe that some
of the patches did not get accepted as they would break our current libGL <>
DRI ABI. The discussion (starting with a few patches) is available in the ML
archives [1].

-Emil

[1] http://lists.freedesktop.org/archives/mesa-dev/2014-March/055617.html

> --Jeremy
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>