[objective_c] Fix build hook

[liamappelbe]

Also added an integration test that runs the path_provider package using the local objective_c. This reproduced flutter/flutter#186794.

Fixes flutter/flutter#186794 (confirmed)
Fixes #3374 (probably)

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:code_assets	1.1.0	already published at pub.dev
package:data_assets	0.20.0	already published at pub.dev
package:ffi	2.2.0	already published at pub.dev
package:hooks	2.0.0	already published at pub.dev
package:hooks_runner	1.3.0	already published at pub.dev
package:jni_flutter	1.0.1	already published at pub.dev
package:native_toolchain_c	0.19.0	already published at pub.dev
package:record_use	0.6.1-wip	WIP (no publish necessary)
package:swift2objc	0.2.0	already published at pub.dev
package:swiftgen	0.1.3	ready to publish	swiftgen-v0.1.3

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[github-actions]

PR Health

Breaking changes ⚠️

Package	Change	Current Version	New Version	Needed Version	Looking good?
objective_c	Breaking	9.3.0	9.4.1	10.0.0 Got "9.4.1" expected >= "10.0.0" (breaking changes)	⚠️

This check can be disabled by tagging the PR with skip-breaking-check.

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbol	Leaking sources

This check can be disabled by tagging the PR with skip-leaking-check.

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

This check can be disabled by tagging the PR with skip-changelog-check.

[dcharkes]

This seems kind of weird right? We change the architecture based on if we run from this workspace or not. Shouldn't it be based on target device?

Maybe arm64e should actually be added to the Architecture in the code config, and then Flutter needs to pass the right architecture to the build hook. (And then Flutter can invoke the build hook for both archs if it wants and combine it into a fat lib for you.)

[liamappelbe]

To me the weird thing is that the AOT bot doesn't like arm64. I thought arm64e machines are supposed to be able to consume arm64 binaries, because arm64e is just an extension. So this line is just to get the AOT tests working on the bots. No users have reported the error that the AOT bot did. Maybe it's because of the strange way we're injecting the dylibs into the binary with an environment variable?

[dcharkes]

• [code_assets] Add arm64e as Architecture? #3379
• [flutter_tool] Distinguish DarwinArch.arm64 and DarwinArch.arm64e? flutter/flutter#186856

I'm fine landing a workaround for now so that we can run arm64e on our CI. But I am kind of surprised that we are somehow forced to run in e.

(And the workaround will likely have to be applied by any downstream users too to run on their CI, because the user-define is in the root package pubspec.)

[liamappelbe]

I don't think downstream users will need to worry about it. I've only seen the error on the new AOT bot, which is using this weird DYLD_INSERT_LIBRARIES workflow. Users won't run into it unless they also try to run AOT tests, at which point they're having to write some custom infra anyway.

Agreed this should probably be fixed by making arm64e a proper architecture though. Otherwise we'll run into the same issue when trying to add native assets support to dart test -c exe.

[dcharkes]

Maybe we don't run into it with dart test -c exe because we'll use the proper native_assets.yaml mapping in the kernel file instead of DYLD_INSERT_LIBRARIES?

[dcharkes]

Okay with the workaround so that we can run on CI.

I've filed flutter/flutter#186856 to explore a proper fix.

Maybe leave a TODO on the workaround.