Changing Cargo.toml name causes failed to load dynamic library on iOS and MacOS

[NathanKolbas]

Describe the bug

This issue is similar to #2747 so I apologize for brining it back up. I have a rust library with the library name foo which I want to create a flutter plugin for. Since I wanted to use the same name foo for the flutter plugin (similar to the prior mentioned issue) I used the same name foo for the flutter plugin. The issue is that flutter_rust_bridge will then run into an issue when scanning the third-party crate due to two cates with the same name foo - again just like the other mentioned issue. To try and get around this issue I just renamed the rust project to foo_wrapper. Here is the command that I used to do that: flutter_rust_bridge_codegen create foo --template plugin --rust-crate-name foo_wrapper --rust-crate-dir rust.

This was working just fine for Windows and Android, however, this causes issues on MacOS and iOS. The podspec file for both platforms had to be updated to search for libfoo_wrapper.a instead of libfoo.a. This works for things to compile, however, during runtime flutter cannot find the dynamic library:

Unhandled Exception: Invalid argument(s): Failed to load dynamic library 'foo_wrapper.framework/foo_wrapper'

This is because the podspec has the name foo so after cargokit is done, CocoPods uses this name to create the framework target which ends up being foo.framework.

During code generation with flutter_rust_bridge, it uses the name of the rust crate for the stem:

flutter_rust_bridge/frb_codegen/src/library/codegen/config/internal_config_parser/generator_parser.rs

Line 142 in 845e45a

stem: compute_default_external_library_stem(rust_crate_dir)

Manually changing this after generation fixes this issue (obviously since it now points to the right framework).

Perhaps supporting Cargo.toml dependency aliasing or an option to change the stem only for iOS and MacOS would resolve this problem? I would need to spend more time investigating a proper fix but that is what I know so far.

Steps to reproduce

Run the following:

flutter_rust_bridge_codegen create foo --template plugin --rust-crate-name foo_wrapper --rust-crate-dir rust

Update the crate name to foo_wrapper if not already set (it didn't for me on MacOS but did on Windows for some reason).
Try to run iOS or MacOS.
Linker will fail.
Run (make sure you are in the example directory):

flutter clean

Update macos/foo.podspec to have:

...
    :script => 'sh "$PODS_TARGET_SRCROOT/../cargokit/build_pod.sh" ../rust foo_wrapper',
...
    :output_files => ["${BUILT_PRODUCTS_DIR}/libfoo_wrapper.a"],
...
    'OTHER_LDFLAGS' => '-force_load ${BUILT_PRODUCTS_DIR}/libfoo_wrapper.a',
  }

Try to run iOS or MacOS.

Logs

N/A

Expected behavior

No response

Generated binding code

OS

Windows and MacOS

Version of flutter_rust_bridge_codegen

2.11.1

Flutter info

Version of clang++

No response

Additional context

No response

[welcome]

Hi! Thanks for opening your first issue here! 😄

[fzyzcjy]

Good point! It seems you already have a fix (or workaround) to make it work, do you have interest in making a PR for that?

[NathanKolbas]

I don't have a fix implemented for flutter_rust_bridge but I would love to make a PR when I have some time. I want to clarify some things to make sure I have the right implementation.

On iOS/MacOS, to fix the issue of having a rust crate with a different name then the flutter library the stem should be the same name as the .podspec file's s.name (which is usually the same as the flutter library). This way flutter is able to find the correct dynamic library. The stem should remain the same for the other platforms. Also, the generated .podspec file should be looking for lib${crate_name}.a and use the name of the crate for the build_pod script (this is probably already implemented but I will double check). This is only for iOS/MacOS.

Adding support for crate aliases.

Does this sound right? If so I can work on the PR for the first when I have a minute.

[fzyzcjy]

my naive thought is that, as long as the implementation follows https://matejknopp.com/post/flutter_plugin_in_rust_with_no_prebuilt_binaries/ / https://github.com/irondash/cargokit then it should be good, since frb uses cargokit and creates a template to generate what is mentioned in the cargokit blog.

[NathanKolbas]

Perfect! That was what I was thinking as well. I can work with that and get something put together.

[fzyzcjy]

looking forward to it!