Compile issues on ARM architecture

[maxpert]

I've been trying to build a SQLite extension on top of library. I am getting multiple compile issues on all ARM builds. Here is my workflow logs. Is there a plan to support ARM and architecture at-least? I believe it's important that we support ARM because most of mobile devices (and potential future macs/desktops are ARM).

[asg017]

Yes, I definitely want to support ARM architectures!

From your errors, it seems like in the sqlite3ext-sys build, ARM architectures gives the underlying C type const char * a Rust type of *const i8. This is different on builds I've done in the past, where the bindgen generated type is *const u8, which is causing those "expected i8, found u8" errors.

I hope this will be an easy fix, but I'll take a closer look when I have time.

Do you mind sharing how are you doing ARM builds in github actions? I haven't explored that yet

[maxpert]

Have a look at https://github.com/maxpert/sqlite-y-crdt/blob/master/.github/workflows/build-test.yml for various architectures I am building for. It should cover all ARM machines including libmusl

[iulianbarbu]

I am experiencing errors on the same lines as mentioned. Compiling against aarch64-unknown-linux-gnu. A sample below:

 error[E0308]: mismatched types
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/sqlite-loadable-0.0.5/src/table.rs:755:51
    |
755 |                 let rc = sqlitex_declare_vtab(db, c_sql.as_ptr());
    |                          --------------------     ^^^^^^^^^^^^^^ expected `*const i8`, found `*const u8`
    |                          |
    |                          arguments to this function are incorrect
    |
    = note: expected raw pointer `*const i8`
               found raw pointer `*const u8`
note: function defined here
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/sqlite-loadable-0.0.5/src/ext.rs:318:15
    |
318 | pub unsafe fn sqlitex_declare_vtab(db: *mut sqlite3, s: *const i8) -> i32 { 

[asg017]

@iulianbarbu that'll be fixed in a soon-to-be-released v0.0.6, in the meantime you can point to the main branch of this repo to get the fix. There's a few unrelated WIP features that'll throw some compiler warnings, though