[Mesa-dev] [PATCH] mesa: do not use _glapi_new_nop_table() for DRI builds

[Brian Paul]

On 05/26/2015 12:21 PM, Ian Romanick wrote:
> On 05/26/2015 11:17 AM, Brian Paul wrote:
>> On 05/26/2015 12:07 PM, Ian Romanick wrote:
>>> On 05/21/2015 06:19 PM, Brian Paul wrote:
>>>> Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
>>>> _glapi_set_nop_handler() functions in the glapi dispatcher (which
>>>> live in libGL.so).  The calls to those functions from context.c
>>>> would be undefined (i.e. an ABI break) if the libGL used at runtime
>>>> was older.
>>>>
>>>> For the time being, use the old single generic_nop() function for
>>>> non-Windows builds to avoid this problem.  At some point in the future
>>>> it should be safe to remove this work-around.  See comments for more
>>>> details.
>>>>
>>>> v2: Incorporate feedback from Emil.  Use _WIN32 instead of
>>>> GLX_DIRECT_RENDERING to control behavior, move comments.
>>>>
>>>> Cc: 10.6 <mesa-stable at lists.freedesktop.org>
>>>> ---
>>>>    src/mesa/main/context.c | 62
>>>> +++++++++++++++++++++++++++++++++++++++++++++++--
>>>>    1 file changed, 60 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
>>>> index 544cc14..02875ba 100644
>>>> --- a/src/mesa/main/context.c
>>>> +++ b/src/mesa/main/context.c
>>>> @@ -883,6 +883,19 @@ update_default_objects(struct gl_context *ctx)
>>>>    }
>>>>
>>>>
>>>> +/* XXX this is temporary and should be removed at some point in the
>>>> + * future when there's a reasonable expectation that the libGL library
>>>> + * contains the _glapi_new_nop_table() and _glapi_set_nop_handler()
>>>> + * functions which were added in Mesa 10.6.
>>>> + */
>>>
>>> The other way would be to use dlsym determine whether or not the
>>> function is available.  That should work on most or all ELF systems.  We
>>> could also use the usual DRI extension mechanism.  That's the generally
>>> accepted way to advertise new, optional libGL functionality to drivers.
>>
>> OK, I can look into that someday.
>>
>>>
>>> Either way, this patch is
>>>
>>> Reviewed-and-tested-by: Ian Romanick <ian.d.romanick at intel.com>
>>
>> Thanks!
>
> Arg.  You didn't 'make check', did you? :(  I just tested the "hard"
> part (using new driver with old libGL), and I didn't check the "easy" thing.
>

No, sorry.  I always forget that.

Revert 778c7f149a0e29d135b05f27bb0a6837decdb533 to fix this?

-Brian