Opened 16 months ago

Last modified 16 months ago

#3610 new defect

Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work (almost)

Reported by: vince Owned by: grass-dev@…
Priority: normal Milestone:
Component: Default Version: unspecified
Keywords: Cc:
CPU: Unspecified Platform: Unspecified

Description

ctypesgen miserably fails on MacOS. I found the situation could be much improved if you add this defines: \"-Drestrict=\" \"-D_ _attribute_ _(x)=\" \"-D_Nullable=\" \"-D_Nonnull=\" to CTYPESFLAGS

The situation is not ideal, however. cpl_port.h as installed by GDAL needs a small patch too, because <x86intrin.h> won’t parse. I’m planning to ask the GDAL developers if this line is mandatory with CLANG. In the meanwhile the Makefile should make a private copy of this file, modify it and use it.

Also, a system file needs a patch, though that might not be necessary (#warning condition treated as an error).

Finally, NVIZ is beyond hope. The AGL framework is deprecated, uses Carbon as a framework, which is still more deprecated, and that makes the parsing almost impossible to set straight. Does grass rely on NVIZ, or it is possible to add an option to disable 3D viz? That'd be nice.

Thanks.

Attachments (1)

fedora28_grass_trunk_ctypes_build.log (86.7 KB) - added by neteler 16 months ago.
F28 build log of ctypes with parse errors

Download all attachments as: .zip

Change History (13)

comment:1 Changed 16 months ago by cmbarton

I don't understand the NVIZ comment. It is currently working fine with the newest High Sierra OS X, compiled 64 bit, with wxPython 4.0. We may run into problems down the line of course, but it is not a problem now. Also Huidae Cho just managed to fix m.nviz.image for the Mac, updating its use of OpenGL.

comment:2 Changed 16 months ago by hcho

By default (without #define OPENGL_AGL 1 in config.h), trunk uses the Core OpenGL (CGL), which is the lowest-level OpenGL API for the Mac. The AGL code is still there just in case, but not used anymore since r73006.

Last edited 16 months ago by hcho (previous) (diff)

comment:3 Changed 16 months ago by vince

I don’t imply it’s not working. It’s the CTYPEGEN parsing which generates a lot of errors. Maybe I’m misconfiguring GRASS, so I’ll check out once more and hopefully come back with updated info.

comment:4 Changed 16 months ago by vince

Ah, this hasn't made it to a release yet. Is the new OpenGL based code activated by using --with-opengl=osx in configure? Thanks

PS: I don’t want to rain on the parade in any way, but OpenGL will be officially deprecated in OS X Mojave 10.14 to be released during fall… :( :(

Last edited 16 months ago by vince (previous) (diff)

Changed 16 months ago by neteler

F28 build log of ctypes with parse errors

comment:5 Changed 16 months ago by neteler

Also on Fedora 28 parse errors occur: attached the F28 build log excerpt of ctypes subdir

comment:6 in reply to:  5 Changed 16 months ago by hellik

Replying to neteler:

Also on Fedora 28 parse errors occur: attached the F28 build log excerpt of ctypes subdir

see also, maybe related

#3368 #3464

comment:7 Changed 16 months ago by vince

I suspect most of your errors stem from this line (around 690) in cpp_port.h, which is part of GDAL:

#include <x86intrin.h>

If you comment this line, do you still have those errors? If not, then it'd be worth to consider what I suggested: use a slightly altered version of this include file, copying it locally and commenting out that line which does not contribute to anything in ctype

comment:8 in reply to:  4 Changed 16 months ago by hcho

Replying to vince:

Ah, this hasn't made it to a release yet. Is the new OpenGL based code activated by using --with-opengl=osx in configure? Thanks

PS: I don’t want to rain on the parade in any way, but OpenGL will be officially deprecated in OS X Mojave 10.14 to be released during fall… :( :(

Yep! Like always, they've created their own stuff (innovation?), Metal API. Hopefully, there will be an Open Source wrapper library that provides a cross-platform abstract layer for both OpenGL and Metal.

comment:9 Changed 16 months ago by vince

To be honest, OpenGL is a technology born in the 80s, and I think it has really overstayed its welcome.

Apple could have moved to Vulkan. They chose to go their own path. You’re right, this wasn't really smart. I suspect the Khronos group is fraught with tension between the various manufacturers, and Apple might have bowed out after being met with ferocious opposition (especially from Nvidia).

I’m also very sorry they decided to deprecate OpenCL.

comment:10 Changed 16 months ago by cmbarton

So what's a potential cross-platform 3D rendering engine to replace OpenGL in future NVIZ?

comment:11 Changed 16 months ago by vince

There is, I think, an open-source library that abstracts the Metal API into a Vulkan compatible API. That might work.

comment:12 in reply to:  7 Changed 16 months ago by neteler

Replying to vince:

I suspect most of your errors stem from this line (around 690) in cpp_port.h, which is part of GDAL:

Guess you mean /usr/include/gdal/cpl_port.h

#include <x86intrin.h>

If you comment this line, do you still have those errors? If not, then it'd be worth to consider what I suggested: use a slightly altered version of this include file, copying it locally and commenting out that line which does not contribute to anything in ctype

Confirmed! All ctype parse issues are gone then on my Fedora 28 box by commenting that line in /usr/include/gdal/cpl_port.h

Note: See TracTickets for help on using tickets.