[Mesa-dev] [PATCH mesa] meson: add GL/glext.h warning fix for MacOS

Jeremy Sequoia jeremyhu at apple.com
Fri Jun 15 17:43:43 UTC 2018



Sent from my iPhone...

> On Jun 15, 2018, at 09:35, Eric Engestrom <eric.engestrom at intel.com> wrote:
> 
>> On Friday, 2018-06-15 08:14:40 -0700, Jeremy Huddleston Sequoia wrote:
>> I think we can instead revert c7f3657450683827446072ad6b1e8fce04078162.
> 
> If you think the issue is resolved, then please feel free to send that
> revert :)

Thanks. I’ll give it a try next week and get back to ya.

> Is there a way for someone without a Mac to test this?

I suppose you could change the __APPLE__ check to APPLE_GLHANDLEARB and have that toggled by a configure check (with appropriate defaults for the platforms.  However, I would have concerns over such a change because that would make it very easy for someone to go the wrong way in a production environment, and we would be even worse off than we are now.

However just changing the GLhandleARB typeset locally to void * in an isolated test environment should be enough to reproduce and test locally.

>> I believe the underlying issue should instead be addressed by
>> a087a09fa86f9617af98f6294dd2228555a4891c.  If any issues remain, we
>> should address them properly rather than masking them with this.
>> 
>> A quick audit makes me suspect we'll get some (benign) 32-64 pointer
>> conversion warnings in some cases which can be addressed like this:
>> 
>> void GLAPIENTRY
>> _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
>>                             GLsizei * count, GLhandleARB * obj)
>> {
>>    GET_CURRENT_CONTEXT(ctx);
>> -   get_attached_shaders(ctx, (GLuint)container, maxCount, count, NULL, obj);
>> +   get_attached_shaders(ctx, (GLuint)(uintptr_t)container, maxCount, count, NULL, obj);
>> }
>> 
>> I think that is preferable to masking the problem.  If you prefer,
>> I can do a pass to fixup the casting followed by a revert of
>> c7f3657450683827446072ad6b1e8fce04078162 separate from your series.
>> 
>> Thanks,
>> Jeremy
>> 
>>> On Jun 15, 2018, at 6:41 AM, Jon Turney <jon.turney at dronecode.org.uk> wrote:
>>> 
>>> On 12/06/2018 16:53, Dylan Baker wrote:
>>>> Quoting Eric Engestrom (2018-06-12 04:25:10)
>>>>> Copied from configure.ac:1950
>>>>> 
>>>>> Signed-off-by: Eric Engestrom <eric.engestrom at intel.com>
>>>>> ---
>>>>> Is it still needed? We've been building on MacOS for a while,
>>>>> yet nobody noticed anything (Dylan?)
>>>>> If not, we should probably avoid unnecessary differences with Khronos'
>>>>> headers and nuke BUILDING_MESA.
>>>>> ---
>>>>> meson.build | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>> 
>>>>> diff --git a/meson.build b/meson.build
>>>>> index c5acc8a3587ea20e131e..04b3bdfd77f36670ff7f 100644
>>>>> --- a/meson.build
>>>>> +++ b/meson.build
>>>>> @@ -209,6 +209,7 @@ endif
>>>>>   if host_machine.system() == 'darwin'
>>>>>   with_dri_platform = 'apple'
>>>>> +  pre_args += '-DBUILDING_MESA'
>>>>> elif ['windows', 'cygwin'].contains(host_machine.system())
>>>>>   with_dri_platform = 'windows'
>>>>> elif system_has_kms_drm
>>>>> -- 
>>>>> Cheers,
>>>>>  Eric
>>>>> 
>>>> I didn't notice, but I also didn't do a whole lot of testing
>>>> I've added Jon who did most of the meson mac work and Jeremy who's the resident
>>>> mac expert.
>>> No expert, but I believe this is unfortunately still needed.
>>> 
>>> See commit c7f36574 and the referenced BZ.
>> 


More information about the mesa-dev mailing list