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

[Ian Romanick]

On 05/26/2015 11:36 AM, Brian Paul wrote:
> 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?

I sent out what I hope is a more future-proof solution.  I originally
sent it squashed with your patch, but I was too slow.

> -Brian