tursodatabase / libsql

libSQL is a fork of SQLite that is both Open Source, and Open Contributions.

Home Page:https://turso.tech/libsql

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

iOS/Android support

ospfranco opened this issue · comments

I'm trying to build static library (.a) that I can use on iOS and Android. I'm trying to compile the C experimental bindings, doing cargo build --target [TARGET] --release works and compiles the library correctly.

The problem however lies when I try to create all three iOS archs (x86_64-apple-ios, aarch64-apple-ios, aarch64-apple-ios-sim) and then generate a single fat binary for x86_64-apple-ios and aarch64-apple-ios-sim, which is needed to package all of them in a single .xcframework

I get the following error:

lipo -create ../../target/x86_64-apple-ios/release/libsql_experimental.a ../../target/aarch64-apple-ios-sim/release/libsql_experimental.a -output generated/simulator_fat/libsql_experimental.a
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: archive member ../../target/x86_64-apple-ios/release/libsql_experimental.a(sqlite3mc.c.o) cputype (16777228) and cpusubtype (0) does not match previous archive members cputype (16777223) and cpusubtype (3) (all members must match)
make: *** [libsql.xcframework] Error 1

Which seems to indicate the sqlite3mc.c object file has not been compiled for the correct architecture.

Are there some instructions to compile the library to iOS/Android? I've seen at least one person that has managed to compile it for Android.

I successfully ran libsql on Android. I don't think I had to do anything special. What I do though is having a new Rust lib project that depends on libsql.

Running lipo on the generated .a for x86_64 allowed me to pin point the problem:

lipo -info ../../target/x86_64-apple-ios/release/libsql_experimental.a                                                                                   
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: archive member ../../target/x86_64-apple-ios/release/libsql_experimental.a(sqlite3mc.c.o) cputype (16777228) and cpusubtype (0) does not match previous archive members cputype (16777223) and cpusubtype (3) (all members must match)

Indeed it seems the cargo build is targeting apple ios x86_64 but the generated sqlite object file has been compiled for another arch. Looking at the build script I find nothing weird. The cc crate is used for compiling the sqlite source file which should handle cross compilation gracefully. So it seems this path with a cmake build is happening (maybe due the encryption feature being turned on?).

I've added the following to try to make cross compilation work, but it doesn't seem to be doing anything:

if target.contains("x86_64-apple-ios") {
    cmake_opts.push(&cmake_toolchain_opt);
    writeln!(toolchain_file, "set(CMAKE_SYSTEM_NAME \"iOS\")").unwrap();
    writeln!(toolchain_file, "set(CMAKE_SYSTEM_PROCESSOR \"x86_64\")").unwrap();
}

Edit: turning off the encryption feature does indeed allow the crate to compile successfully. Seems indeed the cmake compilation is off for non-host architectures.

@ospfranco yep, encryption library build system has a complicated cmake<->cargo relationship, and it's not adjusted for cross compiling, it would require a few changes or manual steps. If you don't need encryption at rest, best just to skip it

Yeah, I ended up removing the encryption feature and it is working. I have another issue. The openRemote function is working for iOS but on android there is a certificate error. I'm guessing it is missing openSSL, do you know if I can fix this easily or I need to change the build process to somehow include openSSL

Sounds like an issue with lack of local certs in Android, maybe? I remember reading about https://crates.io/crates/rustls-platform-verifier once as a workaround, but never went further than research

Created a new ticket for that issue:

#1432

Closing this one as sqlcipher support is not planned at least for now :)