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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
