py-grpcio: various buildbot failures

[mascguy (Christopher Nielsen)]

There are a few different issues with this port build, depending on the platform.

The following is what we're seeing for the latest buildbot jobs:

Big Sur x86_64:

​https://build.macports.org/builders/ports-11_x86_64-builder/builds/31390/steps/install-port/logs/stdio

distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "11.0" but "11.2" during configure

10.6:

​https://build.macports.org/builders/ports-10.6_x86_64-builder/builds/57438/steps/install-port/logs/stdio

error: invalid argument '-std=c++11' not allowed with 'C'

For 10.7 through 10.9:

​https://build.macports.org/builders/ports-10.7_x86_64-builder/builds/53892/steps/install-port/logs/stdio

​https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/47452/steps/install-port/logs/stdio

​https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/147853/steps/install-port/logs/stdio

In file included from src/core/lib/iomgr/gethostname_sysconf.cc:26:
In file included from /opt/local/include/LegacySupport/unistd.h:92:
In file included from /usr/include/unistd.h:72:
/opt/local/include/LegacySupport/sys/unistd.h:76:16: error: unknown type name 'size_t'
                         void *buf, size_t size, uint32_t flags);
                                    ^

This might be a case of blacklisting older clang versions, and perhaps blacklisting Xcode clang entirely (if necessary).

[mascguy (Christopher Nielsen)]

Some of these might be fixable with compiler blacklisting.

But others might relate to our portgroups. CJones, any thoughts/ideas?

[cjones051073 (Chris Jones)]

can you attached a complete logs ?

[mascguy (Christopher Nielsen)]

These are all from buildbot jobs that ran within the last 10 minutes, grab them from the waterfall display.

[cjones051073 (Chris Jones)]

I'm on a mobile device and thats not so easy. It would be useful to have parma-links to these logs here as in time they will be hard to find.

[mascguy (Christopher Nielsen)]

Added links to specific buildbot jobs

[mascguy (Christopher Nielsen)]

Attached full logs from the various buildbot jobs, so that they're not lost when build history ages out.

[mascguy (Christopher Nielsen)]

I'll take a look at fixing the builds on 10.6 through 10.9.

CJones/anyone, thoughts regarding the Big Sur failure ($MACOSX_DEPLOYMENT_TARGET mismatch: now "11.0" but "11.2" during configure)?

[mascguy (Christopher Nielsen)]

Actually, the failures on 10.7 through 10.9 all related to size_t not being defined. And we might need to fix this in port legacy-support.

CJones, is there an easy fix for this case, apart from potentially defining it [in legacy-support] when necessary?

[kencu (Ken)]

size_t is defined in that header if needed

​https://github.com/macports/macports-legacy-support/blob/4de7b2b365ffa5afb4ef3c5858ca3ad50b4628ac/include/sys/unistd.h#L39

but it is protected by a guard, and it looks like since the latest changes the guard on defining size_t needs to be broadened a bit.

Baby steps pls...any major hacking on legacysupport is certain to cause more harm than good...so caution is needed.

[mascguy (Christopher Nielsen)]

No worries, there are numerous areas that I simply won't touch at this point. With legacysupport being one of the biggies.

CJones, thoughts about fixing this?

[kencu (Ken)]

you need to make sure size_t is always defined if __MP_LEGACY_SUPPORT_SETATTRLISTAT__ is defined.

It currently is not.

[kencu (Ken)]

the fix is trivial, but the exact way the defines are extended is not.

various compilers handle this differently, and you need a fix that works with gcc-4.2 without causing warnings with clang-devel

[mascguy (Christopher Nielsen)]

Well, I'll let you folks figure this one out.

But I'm happy to help test a potential change, particularly on MacOS 10.7 through 10.9. Let me know!

[mascguy (Christopher Nielsen)]

As for the MacOS 10.6 issue (error: invalid argument '-std=c++11' not allowed with 'C'), it looks like this port is building with Clang 9. So we're already using a modern compiler, and blacklisting won't help. (Unless I'm missing something.)

Any thoughts on this peculiarity?

[kencu (Ken)]

Replying to mascguy:

As for the MacOS 10.6 issue (error: invalid argument '-std=c++11' not allowed with 'C'), it looks like this port is building with Clang 9. So we're already using a modern compiler, and blacklisting won't help. (Unless I'm missing something.)

Any thoughts on this peculiarity?

Newer compilers are ever more strict, and don't let you get away with incorrect building lines.

There is another error after that std=c++11 error anyway, WRT to strnlen, which shouldn't happen as it seems this port is using legacysupport, so that needs looking into too, once time is no longer an important thing and lifespans are into the hundreds of years :>

[mascguy (Christopher Nielsen)]

There is another error after that std=c++11 error anyway, WRT to strnlen, which shouldn't happen as it seems this port is using legacysupport, so that needs looking into too, once time is no longer an important thing and lifespans are into the hundreds of years :>

Hey now, you're a strong advocate of supporting all macOS releases when it's feasible, which I respect (and appreciate). And so if we can get this to build on 10.6, and it's not a lot of work, let's do it!

[kencu (Ken)]

this hopefully will fix the 10.7 to 10.10 parts of this

​https://github.com/macports/macports-ports/commit/ec3d85246d1b349642a1d9488b20a9b2d19af18b

​https://github.com/macports/macports-legacy-support/commit/5b5cb1d9346f21e8ce3c698dd0c59ab7bc926a43

assuming I didn't do anything stupid in the process.

It was just overall simplest and least troublesome to test the size_t define again rather than a mess of troublesome and unpredictable define spaghetti.

[mascguy (Christopher Nielsen)]

Thanks Ken, that fixed the size_t definition issue.

Now I'm seeing errors related to structure 'sockaddr':

:info:build In file included from src/core/lib/iomgr/grpc_if_nametoindex_posix.cc:28:
:info:build In file included from /opt/local/include/LegacySupport/net/if.h:28:
:info:build /usr/include/net/if.h:306:19: error: field has incomplete type 'struct sockaddr'
:info:build                 struct  sockaddr ifru_addr;
:info:build                                  ^
:info:build /usr/include/net/if.h:307:19: error: field has incomplete type 'struct sockaddr'
:info:build                 struct  sockaddr ifru_dstaddr;
:info:build                                  ^
:info:build /usr/include/net/if.h:308:19: error: field has incomplete type 'struct sockaddr'
:info:build                 struct  sockaddr ifru_broadaddr;
:info:build                                  ^
:info:build /usr/include/net/if.h:352:18: error: field has incomplete type 'struct sockaddr'
:info:build         struct  sockaddr ifra_addr;
:info:build                          ^
:info:build /usr/include/net/if.h:353:18: error: field has incomplete type 'struct sockaddr'
:info:build         struct  sockaddr ifra_broadaddr;
:info:build                          ^
:info:build /usr/include/net/if.h:354:18: error: field has incomplete type 'struct sockaddr'
:info:build         struct  sockaddr ifra_mask;
:info:build                          ^
:info:build /usr/include/net/if.h:437:26: error: field has incomplete type 'struct sockaddr_storage'
:info:build         struct sockaddr_storage addr;   /* in/out */
:info:build                                 ^
:info:build /usr/include/net/if.h:438:26: error: field has incomplete type 'struct sockaddr_storage'
:info:build         struct sockaddr_storage dstaddr; /* out */
:info:build                                 ^
:info:build 8 errors generated.

[mascguy (Christopher Nielsen)]

Ken/Chris, if you can provide some direction, I'd be willing to work on a fix for the 'sockaddr' issue. (At least for the devel version of legacy-support.)

Assuming this issue isn't more complex than it appears, that is...

[mascguy (Christopher Nielsen)]

Given that these issues have been resolved for Big Sur, as well as 10.9 - closing this is as fixed. We can always reopen if folks are interested in support for 10.8 and earlier.