thlorenz / rid

Rust integrated Dart framework providing an easy way to build Flutter apps with Rust.
64 stars 4 forks source link

Building for macOS-x86_64 but attempting to link with file built for macOS-arm64 #50

Open Roms1383 opened 2 years ago

Roms1383 commented 2 years ago

Hello ! and sorry to come back with another issue ^^'

description

So far I have ./sh/bindgen, ./sh/macos and ./sh/ios running just fine :white_check_mark: but I keep having architecture related issue when running flutter run :boom:

I ended up reinstalling from rid-template-flutter again (from commit 70dbfd0), and got the same result:

Screen Shot 2564-10-19 at 19 54 28

context

local machine

dev-machine

versions


I'm not familiar with the build tooling like XCode etc so apologies if this is a beginner question :pray:

thlorenz commented 2 years ago

Make sure to do flutter run -d macos to start up the OSX version, somehow to me it looks like the macos binary didn't get built or put in the right place. Could you run the following please? ls -la plugin/macos/*.a

It should show a file, otherwise that is the issue.

Also please just copy and paste terminal output as text instead of as images (much easier to parse and work with). Add them inside a markdown codeblock for to make it look good 😉

thlorenz commented 2 years ago

Ah seeing the issue now .. the file is there but it cannot link it since it's built for a different architecture. What mac are you on? Is it an M1 chip by chance? In either case you may have to change the target inside ./sh/macos in my case it is:

MACOS_TARGETS=aarch64-apple-ios

In your case you may have to change it so that Rust compiles an architecture that is compat with Flutter.

Roms1383 commented 2 years ago

Yes, M1 chip indeed! @thlorenz Long story short, this is actually what I tried in the meantime, but without any success so far.

⚠️ there is one thing that confused me though before I go further: it's that I've searched both my workspace and rid repository without finding any usage of MACOS_TARGETS. So I presumed it's an environment var and went searching on Google for it but I couldn't find any clear mention or documentation of it. Could it be misspelled ?


also, you asked

Could you run the following please? ls -la plugin/macos/*.a

Indeed, the file is here:

-rw-r--r--  1 romain  staff  17045752 Oct 20 09:57 plugin/macos/libagent.a

more details

In the meantime I found out mentions of the issue with architecture related to M1 + Cocoapods / XCode on Stackoverflow and finally stumbled upon the MACOS_TARGETS too.

So I tried updating it to x86_64-apple-darwin:

rustup target add x86_64-apple-darwin

Then updated MACOS_TARGETS=x86_64-apple-darwin in ./sh/macos and ran:

./sh/bindgen && ./sh/macos && flutter run -d macos

Which builds fine, but keep crashing with the same error on flutter run -d macos.

thlorenz commented 2 years ago

Actually you're right MACOS_TARGETS isn't actually used in the build script, i.e. here.

You want to look into rust cross compilation in order to force the target via the --target flag.

It could be as simple as changing the cargo build ... line to something like:

cargo build --target $MACOS_TARGETS && cp $LIB_SOURCE_FILE $LIB_TARGET_FILE

What you did so far (adding another rust target via rustup target add x86_64-apple-darwin) is in the right direction, but to target it when compiling has to be done as well.

Hope this helps. I don't have an M1, so I cannot reproduce this unfortunately, but please ask more questions if things don't work out.

Roms1383 commented 2 years ago

Ok so far as you suggested I've tried with --target=x86_64-apple-darwin in ./sh/macos, which didn't change the output.

I've started to wonder if it's also related to ./sh/bindgen since the error message says _libagent.a, building for macOS-x8664 but attempting to link with file built for macOS-arm64, so I tried a quick edit like so:

#!/usr/bin/env bash

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"

cd $DIR/.. && cargo run --target=x86_64-apple-darwin --bin=rid_build

which yielded a different error:

❯ ./sh/bindgen && ./sh/macos && flutter run -d macos
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
     Running `/Users/romain/Development/sandbox/dataterm/target/x86_64-apple-darwin/debug/rid_build rid_build`
2021-10-20 23:00:43,641 INFO [rid_build] Generating bindings
2021-10-20 23:00:44,091 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::RidVec.
2021-10-20 23:00:44,094 INFO [rid_build] Generating Dart glue code
2021-10-20 23:00:44,094 INFO [rid_build] Injecting Swift code into plugin
2021-10-20 23:00:44,096 DEBUG [rid_build::ffigen::run_ffigen] Running '"dart" "run" "ffigen" "--config" "/var/folders/f9/wg0kh90517b1y_stm7qc0ztc0000gn/T/.tmp5QGfkI/ffigen_config.yaml"' from: '"/Users/romain/Development/sandbox/dataterm/agent"'
    Finished dev [unoptimized + debuginfo] target(s) in 0.17s
Launching lib/main.dart on macOS in debug mode...
--- xcodebuild: WARNING: Using the first of multiple matching destinations:
{ platform:macOS, arch:x86_64, id:DD7B1F9D-D0BA-5DB5-8574-1DC73431BFAC }
{ platform:macOS, name:Any Mac }
lib/main.dart:9:9: Error: Type 'Store' not found.
  final Store _store = Store.instance;
        ^^^^^
lib/main.dart:24:9: Error: Type 'Store' not found.
  final Store _store;
        ^^^^^
plugin/lib/generated/rid_api.dart:180:1: Error: Type 'ffigen_bind.NativeLibrary' not found.
ffigen_bind.NativeLibrary _initRidFFI() {
^^^^^^^^^^^^^^^^^^^^^^^^^
lib/main.dart:9:9: Error: 'Store' isn't a type.
  final Store _store = Store.instance;
        ^^^^^
lib/main.dart:9:24: Error: Getter not found: 'Store'.
  final Store _store = Store.instance;
                       ^^^^^
lib/main.dart:24:9: Error: 'Store' isn't a type.
  final Store _store;
        ^^^^^
plugin/lib/generated/rid_api.dart:183:10: Error: Method not found: 'NativeLibrary'.
  return ffigen_bind.NativeLibrary(_dl);
         ^^^^^^^^^^^^^

Command PhaseScriptExecution failed with a nonzero exit code
note: Using new build system
note: Planning
note: Build preparation complete
note: Building targets in parallel
** BUILD FAILED **

Building macOS application...                                           
Exception: Build process failed

Looking closely at it, it appears that bindgen didn't generate the bindings correctly, as previously it was:

2021-10-20 23:18:28,665 INFO [rid_build] Generating bindings
2021-10-20 23:18:29,267 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::Store - opaque (Struct is not marked #[repr(C)] or #[repr(transparent)].).
2021-10-20 23:18:29,267 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::Msg.
2021-10-20 23:18:29,267 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::Reply.
2021-10-20 23:18:29,274 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::_to_dart_for_Store.
2021-10-20 23:18:29,276 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_store_debug.
2021-10-20 23:18:29,276 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_store_debug_pretty.
2021-10-20 23:18:29,276 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::RidStoreAccess - opaque (Struct is not marked #[repr(C)] or #[repr(transparent)].).
2021-10-20 23:18:29,277 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::create_store.
2021-10-20 23:18:29,280 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_store_lock.
2021-10-20 23:18:29,280 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_store_unlock.
2021-10-20 23:18:29,282 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_store_free.
2021-10-20 23:18:29,283 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_store_count.
2021-10-20 23:18:29,283 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::_include_Store_field_wrappers.
2021-10-20 23:18:29,283 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::str - opaque (Struct is not marked #[repr(C)] or #[repr(transparent)].).
2021-10-20 23:18:29,283 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::CString - opaque (Struct is not marked #[repr(C)] or #[repr(transparent)].).
2021-10-20 23:18:29,283 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_cstring_free.
2021-10-20 23:18:29,283 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_init_msg_isolate.
2021-10-20 23:18:29,283 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_init_reply_isolate.
2021-10-20 23:18:29,290 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_msg_Inc.
2021-10-20 23:18:29,290 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::rid_msg_Add.
2021-10-20 23:18:29,295 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::include_reply.
2021-10-20 23:18:29,295 INFO [cbindgen::bindgen::parser] Take rid_agent_expanded::RidVec.

Could this be that ffigen is not yet compatible with M1 chip ?

Roms1383 commented 2 years ago

By the way my local Dart version is:

❯ dart --version   
Dart SDK version: 2.14.4 (stable) (Wed Oct 13 11:11:32 2021 +0200) on "macos_x64"

I'll try looking atrid_build in the coming days but if you get any hint let me know.

thlorenz commented 2 years ago

Wow I honestly have no idea at this point what's going on, but the errors you're seeing originate from this step flutter run -d macos I think.

Try running each step one by one and look at the error messages in isolation. If you don't see the ld: Warning ignoring file ... anymore then this indicates that flutter can now link it.

Another thing I'd suggest is jumping into the root of the rid repo and running make test to see if they pass.

Then you could just try to get the Dart only example to build and run.

Otherwise could you maybe launch your terminal with Rosetta and see if that works around M1 issues?

Roms1383 commented 2 years ago

Wow I honestly have no idea at this point what's going on, but the errors you're seeing originate from this step flutter run -d macos I think.

Yes flutter run -d macos fails because the bindings are by default for arm64, then when correctly targetting x86_64 it fails because bindgen, or more precisely dart run ffigen, fails to generate all the required bindings.


Try running each step one by one and look at the error messages in isolation.

I did, it yielded the same errors.


Another thing I'd suggest is jumping into the root of the rid repo and running make test to see if they pass.

Interestingly enough, it did fail on:
(click to display error)
```sh cd /Users/romain/Development/contributions/rid/tests/dart/field_access && /Applications/Xcode.app/Contents/Developer/usr/bin/make test-all && \ cd /Users/romain/Development/contributions/rid/tests/dart/export && /Applications/Xcode.app/Contents/Developer/usr/bin/make test-all && \ cd /Users/romain/Development/contributions/rid/tests/dart/apps && /Applications/Xcode.app/Contents/Developer/usr/bin/make test-all && \ cd /Users/romain/Development/contributions/rid/tests/dart/framework && /Applications/Xcode.app/Contents/Developer/usr/bin/make test-all /Applications/Xcode.app/Contents/Developer/usr/bin/make test TEST=strings flutter pub get Running "flutter pub get" in field_access... 873ms cargo build --example strings && \ TEST=strings&& cargo run rid_build && \ dart run test ./test/strings.dart Finished dev [unoptimized + debuginfo] target(s) in 0.27s Finished dev [unoptimized + debuginfo] target(s) in 0.02s Running `target/debug/rid_build rid_build` 2021-10-21 09:41:29,450 INFO [rid_build] Generating bindings 2021-10-21 09:41:30,054 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::Store - opaque (Struct is not marked #[repr(C)] or #[repr(transparent)].). 2021-10-21 09:41:30,054 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::Msg. 2021-10-21 09:41:30,054 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::Reply. 2021-10-21 09:41:30,061 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::_to_dart_for_Store. 2021-10-21 09:41:30,061 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::RidStoreAccess - opaque (Struct is not marked #[repr(C)] or #[repr(transparent)].). 2021-10-21 09:41:30,063 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::create_store. 2021-10-21 09:41:30,065 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_store_lock. 2021-10-21 09:41:30,065 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_store_unlock. 2021-10-21 09:41:30,067 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_store_free. 2021-10-21 09:41:30,069 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_store_title. 2021-10-21 09:41:30,069 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_store_title_len. 2021-10-21 09:41:30,069 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_store_ctitle. 2021-10-21 09:41:30,070 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_store_ctitle_len. 2021-10-21 09:41:30,071 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::_include_Store_field_wrappers. 2021-10-21 09:41:30,071 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::str - opaque (Struct is not marked #[repr(C)] or #[repr(transparent)].). 2021-10-21 09:41:30,071 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::CString - opaque (Struct is not marked #[repr(C)] or #[repr(transparent)].). 2021-10-21 09:41:30,071 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_cstring_free. 2021-10-21 09:41:30,071 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_init_msg_isolate. 2021-10-21 09:41:30,071 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_init_reply_isolate. 2021-10-21 09:41:30,075 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::rid_msg_NotUsed. 2021-10-21 09:41:30,079 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::include_reply. 2021-10-21 09:41:30,080 INFO [cbindgen::bindgen::parser] Take rid_field_access_expanded::RidVec. 2021-10-21 09:41:30,083 INFO [rid_build] Generating Dart glue code 2021-10-21 09:41:30,083 INFO [rid_build] Injecting Swift code into plugin 2021-10-21 09:41:30,084 DEBUG [rid_build::ffigen::run_ffigen] Running '"dart" "run" "ffigen" "--config" "/var/folders/f9/wg0kh90517b1y_stm7qc0ztc0000gn/T/.tmp5N7ZR6/ffigen_config.yaml"' from: '"/Users/romain/Development/contributions/rid/tests/dart/field_access"' thread 'main' panicked at 'Build failed: 'dart run ffigen' failed to run successfully stderr: Could not find a file named "pubspec.yaml" in "/Users/romain/.pub-cache/hosted/pub.dartlang.org/_fe_analyzer_shared-23.0.0". stdout: ', rid_build.rs:28:26 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace make[2]: *** [test] Error 101 make[1]: *** [test-all] Error 2 make: *** [test_integration] Error 2 ```

Otherwise could you maybe launch your terminal with Rosetta and see if that works around M1 issues?

Ah yes I gave a try too, but it didn't change the outcome.

thlorenz commented 2 years ago

This error seems to be the problem:

stderr: Could not find a file named "pubspec.yaml" in "/Users/romain/.pub-cache/hosted/pub.dartlang.org/_fe_analyzer_shared-23.0.0".

You may have some broken install there. That is not directly related to rid.

SecondFlight commented 2 years ago

I had this issue a few times, and I usually got it to go away by running flutter pub get in the rid root folder. (not the project root, though maybe that would work too? or both? or maybe you actually need it in the project root? maybe just run it everywhere??) It's what I think I fixed in the test suite by just always running flutter pub get, but I never did figure out how to reproduce the original issue.

Roms1383 commented 2 years ago

oh thanks ! I can't test it right away but let me get back to you on Monday 😃

Roms1383 commented 2 years ago

@thlorenz @SecondFlight well actually I finally found out and it was ... actually way simpler than expected 😅

additional install

:warning: no need for Rosetta

but ffi version must be installed for M1 chip arch like this:

arch -x86_64 sudo gem install ffi

sh/bindgen

# ...
cargo run --target=x86_64-apple-darwin --bin=rid_build

sh/macos

# ...

# TARGET_DIR
# -------------
# first problem is that, on typical build
# binary and files are placed under `/target` folder
# while when compiling for M1 chip arch these are placed under `/target/x86_64-apple-darwin` folder,
# so basically TARGET_DIR has to be updated in this context

# ...

cargo build --target=x86_64-apple-darwin && \
  cp $LIB_SOURCE_FILE $LIB_TARGET_FILE

I don't really remember when it's necessary to run sh/clean and cargo clean before running sh/bindgen, sh/macos and flutter run -d macos again, but sometimes cleaning is necessary.

I was super happy to see the Counter App run on screen !

thlorenz commented 2 years ago

Awesome @Roms1383. I'm delighted you finally got it to work!

Could we add a section to rid's README? Would you be willing to provide a PR with it? It would mainly be the information that you posted just above + maybe a link to this issue. I think this is sufficiently important and confusing to warrant an entire section, i.e.

Using rid with an M1 Macbook

Roms1383 commented 2 years ago

@thlorenz Utterly ok for the section in the README, I can do it in the following days 👌

On a broader scale, my feeling here is that rid really needs a cargo-like command (with commands like init, clean, build and such). I would be willing to work on this starting from a couple of weeks ahead, but I'm pretty sure I will need your support along the way and that I might not be able to carry it out alone. Is this still part of your roadmap and would you mind providing some assistance ? What's your general feeling about it ?

thlorenz commented 2 years ago

Awesome, gonna look out for that PR 😃

Also WRT to CLI tool that is already on the roadmap and I totally agree that we need something like this.

I kept things driven by scripts to learn a bit more about what actually we need it todo. It's fine if you wanna take a stab at it (could live in it's own repo for now and would be published as separate crate depending on rid). Once it's fully worked out we can integrate it here.

Obviously you can also develop this inside a fork of this monorepo as well ... Just a heads up though, I won't have too much time to dedicate to pitch in/review as I'm switching jobs and have tons of stuff on my plate currently. I hope this will improve in a few weeks.

Roms1383 commented 2 years ago

Well, I'm gonna take a stab at it in a couple of weeks ahead, and see what I can get done. I'll try to avoid soliciting you as much as possible, but same here I have my job which already takes me most of my time.

SecondFlight commented 2 years ago

I don't think this is specific to ARM. I just got the same error on a recent x86 Mac running Big Sur.

I got stuck trying to install the ffi gem. Nothing worked. I bashed my head (and a couple dozen browser tabs) against that for a good couple hours. I suspect user error as I'm pretty new to macOS development.

Just a quick sanity check: is the ffi gem supposed to be necessary? Also, are there any other dependencies I might be missing? I can run the Dart examples, so there's a lot that is working... It seems to be specifically the flutter plugin that's failing on me.

Roms1383 commented 2 years ago

@SecondFlight I remember I had to install the ffi gem too, and in my case with M1 chip it was important to specify the correct arch, as I stated in the install steps. The underlying reason here I'm not sure, so I'll leave the explanation to somebody knowledgeable.

SecondFlight commented 2 years ago

A few updates:

  1. The ffi gem is definitely required on all architectures, not just M1.
  2. I believe there's at least some additional Ruby setup required beyond what's default on macOS. I hope to submit a PR with additional setup instructions at some point.
  3. I don't use macOS but I'm working with someone who does. We got our project to build once early on. Every other time (we tried at least 50 times) we encountered either #51 or another error I hadn't seen before. I'm wondering if clean.sh is still leaving something behind that's causing the new error, but it's difficult to diagnose the new issue due to #51, so I'm leaving this here for now.
thlorenz commented 2 years ago

Thanks for the update. Please keep posting updates in this issue and feel free to provide more PRs with updates to the README that help others get rid setup correctly. I appreciate all help!

enzotar commented 2 years ago

Trying on an M1 but can't get the flutter run -d macOS to pass. Have nearly the same error message as @Roms1383 , followed instructions to the T, cleaning and redoing several times with the same error.

My make test in the rid root has the same error on the pubspec.yaml/_fe_analyzer_shared-23.0.0", but from the thread, it seems unrelated. Did you apply any fixes there?

--- xcodebuild: WARNING: Using the first of multiple matching destinations:
{ platform:macOS, arch:x86_64, id:A1DF7200-AC55-50C0-91DA-F18E39CDCA9E }
{ platform:macOS, name:Any Mac }
Undefined symbols for architecture x86_64:
  "___include_dart_for_hash_map_string_flutteredge", referenced from:
      plugin.dummyCallsToPreventTreeShaking() -> () in Plugin.o

[...]

  "_rid_widgettype_debug_pretty", referenced from:
      plugin.dummyCallsToPreventTreeShaking() -> () in Plugin.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
note: Using new build system
note: Planning
note: Build preparation complete
note: Building targets in dependency order
** BUILD FAILED **
enzotar commented 2 years ago

@Roms1383 Does your build work on the iOS simulator?

Roms1383 commented 2 years ago

@enzotar I'm sorry, actually I didn't have the opportunity to get back on tinkering with rid since December now.

My memory about rid install process a bit rusty tbh, but as far as I remember this error:

ld: symbol(s) not found for architecture x86_64

is usually due to having ffi installed for the wrong architecture on your machine, did you run ?

arch -x86_64 sudo gem install ffi
enzotar commented 2 years ago

I did run it. I thoroughly followed your thread, but somehow still get the error message when running for macOS. Then I tried for iOS and updated xcode to match the x86_64 architecture for builds, but still no luck.

On Sun, Feb 13, 2022, 6:49 PM Roms1383 @.***> wrote:

@enzotar https://github.com/enzotar I'm sorry, actually I didn't have the opportunity to get back on tinkering with rid since December now.

My memory about rid install process a bit rusty tbh, but as far as I remember this error:

ld: symbol(s) not found for architecture x86_64

is usually due to having ffi installed for the wrong architecture on your machine, did you run ?

arch -x86_64 sudo gem install ffi

— Reply to this email directly, view it on GitHub https://github.com/thlorenz/rid/issues/50#issuecomment-1038570454, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIKTHU37OSC45QGOLPO263TU3BUSZANCNFSM5GJEI63A . You are receiving this because you were mentioned.Message ID: @.***>

Roms1383 commented 2 years ago

Sadly I don't have time to look further into it these days (quite busy with work and other concerns). If you found out, please do correct me / mention about the extra step(s) in the README.

Still, here's my M1 configuration on my last (successful) run as a desktop app, hope this helps:

bindgen-m1.sh ```sh #!/usr/bin/env bash DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )" cd $DIR/.. && cargo run --target=x86_64-apple-darwin --bin=rid_build ```
macos-m1.sh ```sh #!/usr/bin/env bash DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )" MACOS_TARGETS=aarch64-apple-ios TARGET_DIR=`cargo metadata --format-version 1 --no-deps | jq ".target_directory" | xargs echo` PROJECT_NAME=`cargo metadata --format-version 1 | jq ".resolve.root" | xargs echo | cut -d ' ' -f1` LIB_NAME=lib$PROJECT_NAME.a # /target/universal/debug UNIVERSAL_DEBUG_DIR="$TARGET_DIR/x86_64-apple-darwin/debug" # 👈 don't forget to update according to your install FLUTTER_MACOS_DIR="$DIR/../plugin/macos" # 👈 don't forget to update according to your install LIB_SOURCE_FILE="$UNIVERSAL_DEBUG_DIR/$LIB_NAME" LIB_TARGET_FILE="$FLUTTER_MACOS_DIR/$LIB_NAME" cargo build --target=x86_64-apple-darwin && \ cp $LIB_SOURCE_FILE $LIB_TARGET_FILE ```

I would then run:

./sh/bindgen-m1 && ./sh/macos-m1 && flutter run -d macos
Roms1383 commented 2 years ago

Notice how each cargo run and cargo build requires to modify UNIVERSAL_DEBUG_DIR and FLUTTER_MACOS_DIR and specify --target=x86_64-apple-darwin when calling commands. Maybe this helps ?

enzotar commented 2 years ago

Thanks. Yes, same configuration but somehow not working. I'll dig some more.

enzotar commented 2 years ago

Found a workaround. @thlorenz Would love to get your feedback on how safe the workaround is and whether you can identify the issue.

Everytime I run bindgen, at random, in addition to some 100 others, some new functions get inserted to the dummyCallsToPreventTreeShaking() in the Plugin.swift file. Sometimes just 1, sometimes several. Every bindgen has a different output. And all start with "___include_dartfor" and are usually associated with some Vector or HashMap I have annotated with Rid in Rust.

And when I run flutter run -d macos, those functions show up with the below error, symbol not found. Once in about 200 bindgens it actually worked out the gate, not sure why.

--- xcodebuild: WARNING: Using the first of multiple matching destinations:
{ platform:macOS, arch:x86_64, id:A1DF7200-AC55-50C0-91DA-F18E39CDCA9E }
{ platform:macOS, name:Any Mac }
Undefined symbols for architecture x86_64:
  "___include_dart_for_vec_txtcommand", referenced from:
      plugin.dummyCallsToPreventTreeShaking() -> () in plugin(Plugin.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
note: Using new build system
note: Planning
note: Build preparation complete
note: Building targets in dependency order
** BUILD FAILED **

And to make it work, I comment it out in the Plugin.swift file.

// <rid:prevent_tree_shake Start>
func dummyCallsToPreventTreeShaking() {
...
//__include_dart_for_vec_txtcommand();
...
}

And so I run bindgen maybe ten times, to get only one of them to show, so I can comment only one function and not multiple.

enzotar commented 2 years ago

This might be leading to the issue. I get the below error but only every 100 builds or so which makes it hard to run the backtrace. And it only happens with the 'Composite' types Vec, HashMap.

error: symbol `__include_dart_for_vec_string` is already defined
  --> src/view.rs:53:1
   |
53 | #[rid::model]
   | ^^^^^^^^^^^^^
   |
   = note: this error originates in the attribute macro `rid::model` (in Nightly builds, run with -Z macro-backtrace for more info)