Native Function Resolution Error on macOS ARM64

[BrutalCoding]

Description:
I encountered an issue while testing the llama_dart project on macOS ARM64 architecture. When running the project, I received the following error:

ArgumentError (Invalid argument(s): Couldn't resolve native function 'llama_context_default_params' in 'package:llama_dart/llama_dart_bindings_generated.dart' : dlsym(RTLD_DEFAULT, llama_context_default_params): symbol not found.)

Background:
I'm working with a cutting-edge experimental feature that the Dart team is likely to port over to Flutter later. This new experimental FFI (Foreign Function Interface) package enables any Flutter/Dart developer to integrate llama_dart into their project by adding it to their pubspec.yaml. Running the app is as simple as typing flutter run in their IDE or terminal. This feature eliminates the need to run cmake to compile binaries for each platform, simplifying the user experience and reducing the effort required to provide platform-specific binaries.

I plan to incorporate this plugin into my other project shady.ai.

Issue Details:
While the plugin successfully compiles, the error mentioned above occurs during runtime. The example app uses the generated bindings to look up a specific symbol, the llama context. This symbol must have a matching address/method in the included binary that was auto-compiled (e.g., llama_dart.dylib). Upon inspecting the binary, I discovered old remnants of the original sum() function, indicating that something isn't working as expected.

I'll be actively working on this issue and will provide updates along the way.

Environment:

• OS: macOS (ARM64)
• Dart Version: [Specify Dart version, if relevant]
• llama_dart Version: 0.0.1

Workaround (if any):
There is no true workaround for this issue that aligns with the intended purpose of the package. The purpose of this FFI package is to simplify integration by seamlessly incorporating C++ source code into the relevant platform projects, eliminating the need for users to compile binaries manually. While you can compile the binary yourself using a similar approach as demonstrated in my previously mentioned project shady.ai, this method deviates from the package's intended workflow. It requires users to engage with low-level tooling such as CMake, which the package aims to abstract away. Ideally, users should not have to think about using CMake or handling binaries directly.

Note to Users:
If you encounter this issue or have additional information that could help resolve it, please feel free to contribute to the discussion. Your insights and experiences are valuable in addressing this problem effectively.