Subcommand stderr: invalid argument "linker-signed", Error: AOT compilation failed Could not sign the new executable

[jmagman]

Seen in https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8814262378734426833/+/u/build_package/stdout

$ dart compile exe bin/main.dart -o build/device_doctor
...
Resolving dependencies...
...
Got dependencies!
Info: Compiling with sound null safety
Subcommand terminated with exit code 1.
Subcommand stderr:
invalid argument "linker-signed"

Error: AOT compilation failed
Could not sign the new executable

Script at https://github.com/flutter/cocoon/blob/4189a23fb892d41c773923cd6b9b982a4d0b11b2/device_doctor/tool/build.sh

Bot is running Mac-10.15.7-19H2 and dart 2.17.0-266.1.beta.

As of 6ef426d and #39106 this is running:

sdk/pkg/dart2native/lib/dart2native_macho.dart

Lines 322 to 323 in b8da709

	final signingProcess = await Process.run(
	'codesign', ['-f', '-o', 'linker-signed', '-s', '-', outputPath]);

Does linker-signed exist on the version of codesign shipped in macOS 10.15? If not, a check for macOS 11+ may need to be added.

In case it's relevant, I see some related chatter in the comments at https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chrome/installer/mac/signing/signing.py#26

cc @sstrickl @mit-mit

[jmagman]

Also, is there a workaround to unwedge this builder while this is investigated?

[godofredoc]

\cc @athomas @whesse

[jmagman]

Also, is there a workaround to unwedge this builder while this is investigated?

We wound up just upgrading to macOS 12 so we don't need a workaround for this immediate issue.

[Stargator]

I am seeing this issue on macOS 10.15.7. I cannot upgrade as a workaround.

I'm just trying to build a normal Dart command-line app.

[matthew-carroll]

I just hit this with a local CLI app that I build. I can't upgrade my OS version. Things were working fine up until, I guess, the latest Dart release within Flutter.

Dart version:

Dart SDK version: 2.17.0 (stable) (Mon May 9 10:36:47 2022 +0200) on "macos_x64"

OS version: 10.15.7

[athomas]

@mkustermann

[sstrickl]

So looking into this, for macOS <11.0, either

1. the linker-signed option doesn't exist, or
2. overwriting the signature of a linker-signed binary still requires the -f/--force flag be passed to codesign.

Since all of our build infrastructure uses macOS >= 11.0, we didn't catch this.

Thus, to fix this, I'm working on CL 245000, which changes the procedure for overwriting an existing dartaotruntime signature to only try using the linker-signed option if the macOS version is >= 11.0. If it is <11.0, or if using linker-signed fails for some other reason, we fall back to just doing a regular signature that will need to be force overwritten.

Once that CL has been reviewed and landed, I'll submit a cherry pick request to include this in stable.

[mkustermann]

@athomas Do we have any devices with macOS < 11.0 we could try out the fix?

[whesse]

Our CI bots are actually running 10.15.7. So our infrastructure is not on 11 or greater.
We must not be testing these commands on our CI?

I have logged into one of our mac bots and verified that the OS is 10.15.7.

[athomas]

The arm64/M1 bots are on Mac-11.6.2 (we can't get any of those with an earlier version), the entire x64 fleet is on 10.15.7 (as stated above).

[sstrickl]

Ah, that explains it. We're not using a published Dart SDK on those bots (which would have a signed dartaotruntime), but instead the locally built SDK, which on X64 won't be signed (as signing is only required on M1).

The code that's failing here only gets run if the original dartaotruntime was signed. So basically, unless we somehow sign the locally built SDK and try it there, this whole section of code will be skipped.

That does give us a way to test this, though, which is to adhoc sign the local dartaotruntime on macOS (which we can do safely on both X64 and M1) before running some of the tests that compile standalone executables. I'll see about doing that.

[mkustermann]

Given this was cherry-picked to stable in #49041, I assume we can close this issue?

[sstrickl]

Ah yes, thanks, let's do so.