Opened 3 years ago
Closed 3 years ago
#62959 closed defect (fixed)
py-grpcio: various buildbot failures
Reported by: | mascguy (Christopher Nielsen) | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | cjones051073 (Chris Jones), emcrisostomo (Enrico Maria Crisostomo) | |
Port: | grpc py-grpcio |
Description (last modified by 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:
distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "11.0" but "11.2" during configure
10.6:
error: invalid argument '-std=c++11' not allowed with 'C'
For 10.7 through 10.9:
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).
Attachments (5)
Change History (29)
comment:1 Changed 3 years ago by mascguy (Christopher Nielsen)
comment:3 Changed 3 years ago by mascguy (Christopher Nielsen)
These are all from buildbot jobs that ran within the last 10 minutes, grab them from the waterfall display.
comment:4 Changed 3 years ago by 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.
comment:5 Changed 3 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
Added links to specific buildbot jobs
comment:6 Changed 3 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
comment:7 Changed 3 years ago by mascguy (Christopher Nielsen)
Summary: | py-grpcio: build failures → py-grpcio: various buildbot failures |
---|
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | py-grpcio-buildbot-log-10.6-x86_64.txt.gz added |
---|
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | py-grpcio-buildbot-log-10.8-x86_64.txt.gz added |
---|
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | py-grpcio-buildbot-log-10.9-x86_64.txt.gz added |
---|
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | py-grpcio-buildbot-log-11.x-x86_64.txt.gz added |
---|
comment:8 Changed 3 years ago by mascguy (Christopher Nielsen)
Attached full logs from the various buildbot jobs, so that they're not lost when build history ages out.
comment:9 Changed 3 years ago by 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)?
comment:10 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | emcrisostomo added |
---|---|
Owner: | changed from emcrisostomo to mascguy |
comment:11 Changed 3 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | py-grpcio-buildbot-log-10.7-x86_64.txt.gz added |
---|
comment:12 Changed 3 years ago by 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?
comment:13 Changed 3 years ago by kencu (Ken)
size_t is defined in that header if needed
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 havking on legacysupport is certain to cause more harm than good...so caution is needed.
comment:14 Changed 3 years ago by 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?
comment:15 Changed 3 years ago by kencu (Ken)
you need to make sure size_t is always defined if __MP_LEGACY_SUPPORT_SETATTRLISTAT__
is defined.
It currently is not.
comment:16 Changed 3 years ago by 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
comment:17 Changed 3 years ago by 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!
comment:18 follow-up: 19 Changed 3 years ago by 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?
comment:19 follow-up: 20 Changed 3 years ago by 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 :>
comment:20 Changed 3 years ago by 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!
comment:21 Changed 3 years ago by 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.
comment:22 Changed 3 years ago by 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.
comment:23 Changed 3 years ago by 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...
comment:24 Changed 3 years ago by mascguy (Christopher Nielsen)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
Some of these might be fixable with compiler blacklisting.
But others might relate to our portgroups. CJones, any thoughts/ideas?