Hi, facing `sqlite3` linker errors while building the iOS App which depends on KMP dependency that ...

# touchlab-tools

[Sanju Naik]

Hi, facing sqlite3 linker errors while building the iOS App which depends on KMP dependency that uses libs.sqldelight.native .

Tried adding -lsqlite3 to Xcode's other linker flags and also passing it as linkerOptions in

listOf(
        iosX64(), // Simulator running on Intel based chips.
        iosArm64(), // Actual devices running on Apple bionic.
        iosSimulatorArm64() // Simulator running on M1 chips.
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "SomeName"
            isStatic = true
            linkerOpts("-lsqlite3")
}}

But still it didn't help, Any idea on how to solve this?
NOTE: the same setup was working when we were depending on KMM as a cocoapods dependency. Adding linker errors in the thread

[Sanju Naik]

[19:49:49]: ▸ ❌   "_sqlite3_load_extension", referenced from:
[19:49:49]: ▸ ⚠️       _co_touchlab_sqliter_sqlite3_sqlite3_load_extension_wrapper189 in GopartnerKMM[8](libco.touchlab:sqliter-driver-cinterop-sqlite3-cache.a.o)
[19:49:49]: ▸ ❌   "_sqlite3_mutex_held", referenced from:
[19:49:49]: ▸ ⚠️       _co_touchlab_sqliter_sqlite3_sqlite3_mutex_held_wrapper213 in GopartnerKMM[8](libco.touchlab:sqliter-driver-cinterop-sqlite3-cache.a.o)
[19:49:49]: ▸ ❌   "_sqlite3_mutex_notheld", referenced from:
[19:49:49]: ▸ ⚠️       _co_touchlab_sqliter_sqlite3_sqlite3_mutex_notheld_wrapper214 in GopartnerKMM[8](libco.touchlab:sqliter-driver-cinterop-sqlite3-cache.a.o)
[19:49:49]: ▸ ❌   "_sqlite3_unlock_notify", referenced from:
[19:49:49]: ▸ ⚠️       _co_touchlab_sqliter_sqlite3_sqlite3_unlock_notify_wrapper239 in GopartnerKMM[8](libco.touchlab:sqliter-driver-cinterop-sqlite3-cache.a.o)
[19:49:49]: ▸ ❌   "_sqlite3_win32_set_directory", referenced from:
[19:49:49]: ▸ ⚠️       _co_touchlab_sqliter_sqlite3_sqlite3_win32_set_directory_wrapper171 in GopartnerKMM[8](libco.touchlab:sqliter-driver-cinterop-sqlite3-cache.a.o)
[19:49:49]: ▸ ❌   "_sqlite3_win32_set_directory16", referenced from:
[19:49:49]: ▸ ⚠️       _co_touchlab_sqliter_sqlite3_sqlite3_win32_set_directory16_wrapper173 in GopartnerKMM[8](libco.touchlab:sqliter-driver-cinterop-sqlite3-cache.a.o)
[19:49:49]: ▸ ❌   "_sqlite3_win32_set_directory8", referenced from:
[19:49:49]: ▸ ⚠️       _co_touchlab_sqliter_sqlite3_sqlite3_win32_set_directory8_wrapper172 in GopartnerKMM[8](libco.touchlab:sqliter-driver-cinterop-sqlite3-cache.a.o)

[Simon Binder]

Which SQLiter version are you on? We had the same problems a while ago and these issues should have been fixed in https://github.com/touchlab/SQLiter/pull/125.

[Sanju Naik]

Where can I check the SQLiter version @Simon Binder? thanks

[Simon Binder]

You could add an explicit dependency on the latest version (which appears to be 1.3.3) or run the dependencies task to view all dependencies and their resolved versions.

[Sanju Naik]

We are using sqldelight = "2.0.0-rc02" , looks like that internally uses older version of SQLiter? Let me try updating sqldelight to latest version. latest version depends on 1.3.3 SQLiter - https://github.com/sqldelight/sqldelight/blob/master/gradle/libs.versions.toml#L8 , hopefully that should resolve the issue

[Sanju Naik]

Thank you, after updating most of the linker errors are resolved but still have this one linker error _sqlite3_load_extension

[20:50:34]: ▸ ❌   "_sqlite3_load_extension", referenced from:
[20:50:34]: ▸ ⚠️       _co_touchlab_sqliter_sqlite3_sqlite3_load_extension_wrapper179 in GopartnerKMM[8](libco.touchlab:sqliter-driver-cinterop-sqlite3-cache.a.o)
[20:50:34]: ▸ ❌ ld: symbol(s) not found for architecture arm64
[20:50:34]: ▸ ❌ clang: error: linker command failed with exit code 1 (use -v to see invocation)

[Simon Binder]

In our projects we ended up not linking sqlite3 at all in the Kotlin build. Instead we depend on the Kotlin framework and https://github.com/sbooth/CSQLite in Swift to link everything together. I'm sure there's a way to fix this as well, but I don't really know how.

[Bijan Cronin]

Are you still facing any errors?

[Sanju Naik]

Yes the error is still present , this error happens only when we build in debug mode for device arm64 architecture. For now we have worked around this by generating release variant when building for device, as long term solution its good to get this fixed.