Open aam opened 2 years ago
cc: @zanderso for triage
It's intentional that that build is using the version of clang coming from the version of Xcode that we use in CI. The build flags will need to be adjusted.
@aam @iskakaushik Could either of you link to the BUILD.gn
file that introduces the problematic flag?
https://chromium-review.googlesource.com/c/chromium/src/+/3646604
I don't think that's where -Wno-deprecated-non-prototype
was introduced. It looks like the flag predates that CL.
But, taking a look at how this is done there, I don't think we'll be able to role zlib forward since we have to build with a version of clang that doesn't know about that flag. An alternative might be to introduce a secondary BUILD.gn
file, but then that becomes tech-debt, which I think we should avoid. If there's no reason to role zlib forward right now, I think we should just stay where we are. Dropping this to P4 assuming the revert is going to role through without issue.
I don't think that's where -Wno-deprecated-non-prototype was introduced. It looks like the flag predates that CL.
Ah, right: https://chromium-review.googlesource.com/c/chromium/src/+/3615937 is the one.
I don't think we'll be able to role zlib forward since we have to build with a version of clang that doesn't know about that flag
How much of a problem is the fact that we use different versions of clang on different bots?
If there's no reason to role zlib forward right now, I think we should just stay where we are.
Reason the zlib was rolled forward was to make sure it compiles with latest clang.
@rmacnak-google
This toolchain discrepancy is probably also responsible for https://github.com/flutter/engine/pull/35310 failing.
Fltuter engine Mac iOS builder fails on new revision of zlib:
From logs of a dart->engine roll
This seems to indicate that clang toolchain on that bot is older compared to other Flutter engine mac bots.
@iskakaushik