You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When adding some new usage of .listener for blocks, I started hitting this error at runtime:
Unhandled Exception: Invalid argument(s): Couldn't resolve native function 'disposeObjCBlockWithClosure' in 'objective_c.framework/objective_c' : No asset with id 'objective_c.framework/objective_c' found. No available native assets. Attempted to fallback to process lookup. dlsym(RTLD_DEFAULT, disposeObjCBlockWithClosure): symbol not found.
It looks like there's nothing guaranteeing that this symbol is preserved, so in certain build configurations it's being dead-code stripped. For some important context here, CocoaPod-based plugins can be built in two configurations: as frameworks that are bundled into the app bundle, or as static libraries that are linked directly into the Runner. This depends on both plugin-level settings and app-level settings. flutter create using a Swift app template defaults to forcing framework builds (for somewhat complicated and mostly legacy reasons), while an Obj-C app template does not. In the new SPM-based system Flutter is moving to, there is a similar divergence in build types depending on whether it's a release build.
I'm currently working on a plugin old enough that its example app is Obj-C, so it uses static library builds. In that app, disposeObjCBlockWithClosure is not present anywhere in my final build; the plugin is being built statically and linked in, but the symbol isn't in the resulting binary, so presumably it's been stripped. I was able to fix my app by adding use_frameworks!, but plugins need to support both modes.
I assume this will be migrating to native assets at some point; I'm not sure how far out that is, and if we need another workaround in the short term.
The text was updated successfully, but these errors were encountered:
The error message indicates it's based on our declarative FFI (e.g. @Native annotations) which works only with the native code asset experiment flag turned on and a hook/build.dart was adding the "native code asset" with an id.
(It does has a fallback path - if nohook/build.dart was used - to look the symbol in the process namespace - so @Native works e.g. for binding with malloc(). On some platforms DynamicLibrary.open(<foo>') will make the symbols available in process namespace - which means a manual open of a library will make declarative API work without hook/build.dart)
It's using the fallback path. package:objective_c is not using a build hook. It's using DynamicLibrary.open on the dylib and subsequently uses @Natives relying on the fact that on iOS and MacOS the symbols are loaded with global visibility.
When adding some new usage of
.listener
for blocks, I started hitting this error at runtime:It looks like there's nothing guaranteeing that this symbol is preserved, so in certain build configurations it's being dead-code stripped. For some important context here, CocoaPod-based plugins can be built in two configurations: as frameworks that are bundled into the app bundle, or as static libraries that are linked directly into the Runner. This depends on both plugin-level settings and app-level settings.
flutter create
using a Swift app template defaults to forcing framework builds (for somewhat complicated and mostly legacy reasons), while an Obj-C app template does not. In the new SPM-based system Flutter is moving to, there is a similar divergence in build types depending on whether it's a release build.I'm currently working on a plugin old enough that its example app is Obj-C, so it uses static library builds. In that app,
disposeObjCBlockWithClosure
is not present anywhere in my final build; the plugin is being built statically and linked in, but the symbol isn't in the resulting binary, so presumably it's been stripped. I was able to fix my app by addinguse_frameworks!
, but plugins need to support both modes.I assume this will be migrating to native assets at some point; I'm not sure how far out that is, and if we need another workaround in the short term.
The text was updated successfully, but these errors were encountered: