Skip to content

Mac plugin_lint_mac failing consistently on unrelated PR #98165

Closed

Description

@zanderso

On 0ce527e, which doesn't look like it should have affected a plugin test. /cc @cyanglaz

https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20plugin_lint_mac/5483/overview

[plugin_lint_mac] [STDOUT] stdout:         /opt/s/w/ir/cache/osx_sdk/XCode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target arm64-apple-macos10.11 -isysroot /opt/s/w/ir/cache/osx_sdk/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -L/Users/chrome-bot/Library/Developer/Xcode/DerivedData/App-fnuhlnrabrbryscrhrnessyodoze/Build/Products/Release -L/opt/s/w/ir/cache/osx_sdk/XCode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -L/Users/chrome-bot/Library/Developer/Xcode/DerivedData/App-fnuhlnrabrbryscrhrnessyodoze/Build/Products/Release/test_plugin_swift -L/opt/s/w/ir/cache/osx_sdk/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/swift -F/Users/chrome-bot/Library/Developer/Xcode/DerivedData/App-fnuhlnrabrbryscrhrnessyodoze/Build/Products/Release -F/opt/s/w/ir/x/t/CocoaPods-Lint-20220209-14900-7a9pgu-test_plugin_swift/Pods/FlutterMacOS -filelist /Users/chrome-bot/Library/Developer/Xcode/DerivedData/App-fnuhlnrabrbryscrhrnessyodoze/Build/Intermediates.noindex/App.build/Release/App.build/Objects-normal/arm64/App.LinkFileList -Xlinker -rpath -Xlinker /usr/lib/swift -Xlinker -rpath -Xlinker /usr/lib/swift -Xlinker -rpath -Xlinker @executable_path/../Frameworks -Xlinker -rpath -Xlinker @loader_path/Frameworks -Xlinker -rpath -Xlinker /opt/s/w/ir/cache/osx_sdk/XCode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -Xlinker -rpath -Xlinker @executable_path/../Frameworks -Xlinker -object_path_lto -Xlinker /Users/chrome-bot/Library/Developer/Xcode/DerivedData/App-fnuhlnrabrbryscrhrnessyodoze/Build/Intermediates.noindex/App.build/Release/App.build/Objects-normal/arm64/App_lto.o -fobjc-link-runtime -L/opt/s/w/ir/cache/osx_sdk/XCode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/chrome-bot/Library/Developer/Xcode/DerivedData/App-fnuhlnrabrbryscrhrnessyodoze/Build/Intermediates.noindex/App.build/Release/App.build/Objects-normal/arm64/App.swiftmodule -ObjC -ltest_plugin_swift -framework FlutterMacOS -framework Cocoa -lPods-App -Xlinker -dependency_info -Xlinker /Users/chrome-bot/Library/Developer/Xcode/DerivedData/App-fnuhlnrabrbryscrhrnessyodoze/Build/Intermediates.noindex/App.build/Release/App.build/Objects-normal/arm64/App_dependency_info.dat -o /Users/chrome-bot/Library/Developer/Xcode/DerivedData/App-fnuhlnrabrbryscrhrnessyodoze/Build/Intermediates.noindex/App.build/Release/App.build/Objects-normal/arm64/Binary/App
[plugin_lint_mac] [STDOUT] stdout:     ld: warning: ignoring file /opt/s/w/ir/x/t/CocoaPods-Lint-20220209-14900-7a9pgu-test_plugin_swift/Pods/FlutterMacOS/FlutterMacOS.framework/FlutterMacOS, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
[plugin_lint_mac] [STDOUT] stdout:     Undefined symbols for architecture arm64:
[plugin_lint_mac] [STDOUT] stdout:       "_FlutterMethodNotImplemented", referenced from:
[plugin_lint_mac] [STDOUT] stdout:           test_plugin_swift.TestPluginSwiftPlugin.handle(_: __C.FlutterMethodCall, result: (Any?) -> ()) -> () in libtest_plugin_swift.a(TestPluginSwiftPlugin.o)
[plugin_lint_mac] [STDOUT] stdout:           function signature specialization <Arg[1] = Dead, Arg[2] = Owned To Guaranteed> of function signature specialization <Arg[1] = [Closure Propagated : reabstraction thunk helper from @escaping @callee_unowned @convention(block) (@unowned Swift.Optional<Swift.AnyObject>) -> () to @escaping @callee_guaranteed (@in_guaranteed Swift.Optional<Any>) -> (), Argument Types : [@escaping @callee_unowned @convention(block) (@unowned Swift.AnyObject?) -> ()]> of test_plugin_swift.TestPluginSwiftPlugin.handle(_: __C.FlutterMethodCall, result: (Any?) -> ()) -> () in libtest_plugin_swift.a(TestPluginSwiftPlugin.o)
[plugin_lint_mac] [STDOUT] stdout:       "_OBJC_CLASS_$_FlutterMethodChannel", referenced from:
[plugin_lint_mac] [STDOUT] stdout:           objc-class-ref in libtest_plugin_swift.a(TestPluginSwiftPlugin.o)
[plugin_lint_mac] [STDOUT] stdout:     ld: symbol(s) not found for architecture arm64
[plugin_lint_mac] [STDOUT] stdout:     clang: error: linker command failed with exit code 1 (use -v to see invocation)

/cc @godofredoc @yusuf-goog @jmagman @stuartmorgan

Activity

  1. added
    P0Critical issues such as a build break or regression
    team-infraOwned by Infrastructure team
    on Feb 10, 2022
  2. zanderso commented on Feb 10, 2022

    @zanderso
    MemberAuthor

    P0 because the tree is closed, and I don't see what to revert to re-open it.

  3. jmagman commented on Feb 10, 2022

    @jmagman
    Member

    @stuartmorgan why does url_launcher now look unfederated? I see #94374 but I don't get it.

    [plugin_lint_mac] [STDOUT]   - url_launcher (from `.symlinks/plugins/url_launcher/ios`)
    [plugin_lint_mac] [STDOUT] 
    [plugin_lint_mac] [STDOUT] EXTERNAL SOURCES:
    ...
    [plugin_lint_mac] [STDOUT]   url_launcher:
    [plugin_lint_mac] [STDOUT]     :path: ".symlinks/plugins/url_launcher/ios"
    

    The test is expecting .symlinks/plugins/url_launcher_ios/ios

    To reopen the tree I think #94374 can be reverted, but it's just going to break again once it's "re-federated".

  4. stuartmorgan-g commented on Feb 10, 2022

    @stuartmorgan-g
    Contributor

    I'm not at a computer to test, but I have a theory. Important context:

    • the test app is depending on url_launcher and url_launcher_macos, with no version constraints
    • today we published a major version bump to url_launcher_macos, to 3.0.0
    • url_launcher hasn't been updated yet to pick up that bump; the latest version requires 2.x

    That means that there are two ways the resolver could go:

    • latest url_launcher, lastest 2.x of url_launcher_macos
    • latest url_launcher_macos, and a version of url_launcher that predates macOS support so that it doesn't conflict with url_launcher_macos 3.x

    I suspect that it did the second, giving you a pre-iOS-federation url_launcher.

    If that's the case, your revert will indeed immediately break the tree again when we update url_launcher (probably tomorrow). I would try instead setting a version constraint on url_launcher that requires a federated version. That could be a specific pin, or something like ">=6.0.16" with no upper bound if you want to get new versions automatically.

  5. jmagman commented on Feb 10, 2022

    @jmagman
    Member

    Ah that makes sense, thanks for the possible explanation. Pinning here #98171

  6. jmagman commented on Feb 10, 2022

    @jmagman
    Member

    #98171 failed, I merged #98166 to reopen the tree while I figure out the right pin to make this work.

  7. stuartmorgan-g commented on Feb 11, 2022

    @stuartmorgan-g
    Contributor

    If that's the case, your revert will indeed immediately break the tree again when we update url_launcher (probably tomorrow).

    This update auto-published very shortly after the revert landed, unfortunately. I didn't realize a revert was landing instead of a pin until it was too late.

    In the short term reverting the revert should work. #98171 is still the right longer term fix though or this could happen again any time we happen to make a breaking change to url_launcher_macos

  8. jmagman commented on Feb 11, 2022

    @jmagman
    Member

    If that's the case, your revert will indeed immediately break the tree again when we update url_launcher (probably tomorrow).

    This update auto-published very shortly after the revert landed, unfortunately. I didn't realize a revert was landing instead of a pin until it was too late.

    In the short term reverting the revert should work. #98171 is still the right longer term fix though or this could happen again any time we happen to make a breaking change to url_launcher_macos

    Yup, on it, just wanted to green the tree even temporarily. I should have pinned this version last time this happened. Test in question passed on #98171, will merge shortly.

  9. github-actions commented on Feb 25, 2022

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  10. locked as resolved and limited conversation to collaborators on Feb 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P0Critical issues such as a build break or regressionpackageflutter/packages repository. See also p: labels.team-infraOwned by Infrastructure team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions