[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