Fix build issue when building against Swift's Static Linux SDK

[clive819]

GRDBSQLite was a .systemLibrary target that required sqlite3.h and a linkable libsqlite3 to be present in the SDK sysroot. This blocks cross-compilation with Swift's Static Linux SDK (musl-static), which ships no system sqlite3 — the build fails at #include <sqlite3.h> in shim.h. This commit makes GRDBSQLite carry its own copy of the SQLite amalgamation so GRDB compiles on every platform without needing a system sqlite3.

Static linking was failing with this error:

.build/checkouts/GRDB.swift/Sources/GRDBSQLite/shim.h:1:10: error: 'sqlite3.h' file not found
 1 | #include <sqlite3.h>
.build/checkouts/GRDB.swift/GRDB/Core/Configuration.swift:10:8: error: could not build C module 'GRDBSQLite'

Verification

Tested with Swift 6.2.3 + Static Linux SDK swift-6.2.3-RELEASE_static-linux-0.0.1:

• swift build of the GRDB package on macOS arm64 — passes (libGRDB-dynamic.dylib links cleanly, ~9 s).
• swift build --swift-sdk x86_64-swift-linux-musl --target GRDBSQLite — passes (~1.5 s).
• swift build --swift-sdk aarch64-swift-linux-musl (full release build of a downstream consumer) — passes (~143 s); resulting binary is ELF aarch64, statically linked, runs on Linux (kernel 5.10), exercises the schema migrator + record protocols + insert/fetch round-trip end-to-end.
• swift build --swift-sdk x86_64-swift-linux-musl -c release (full release build of a downstream consumer) — passes (~80 s); resulting binary is ELF x86-64, statically linked.

Pull Request Checklist

• CONTRIBUTING: You have read https://github.com/groue/GRDB.swift/blob/master/CONTRIBUTING.md
• BRANCH: This pull request is submitted against the development branch.
• DOCUMENTATION: Inline documentation has been updated.
• DOCUMENTATION: README.md or another dedicated guide has been updated.
• TESTS: Changes are tested.
• TESTS: The make smokeTest terminal command runs without failure.

[groue]

Hello, @clive819,

I'm surprised that the proposed changes set the SQLITE_DISABLE_SNAPSHOT flag, and force the use of swift-toolchain-sqlite.

The README of swift-toolchain-sqlite says quite clearly:

It is not intended as a general-purpose SQLite package, nor does it aim to provide Swift wrapper APIs.

And I'm not sure you understand the consequences of setting SQLITE_DISABLE_SNAPSHOT.

This pull request can not be merged.

[clive819]

Thanks for reviewing @groue

Would you be ok with this approach where the package ships the amalgamation directly?

If not, should I open an issue for future consideration to fix static linking?

[groue]

Long story short: opening an issue on the GRDB repo will not help. You can, but it will have no effect.

Instead, since I can see on your GitHub profile that you are involved in the Swift ecosystem, I encourage you to report the difficulties to the competent people.

To feed your reflections, I encourage you to learn from the GRDB+SQLCipher experience.

After all, SQLCipher is just another flavor of SQLite, right? There's much to learn here.

The currently suggested solution for linking GRDB with SQLCipher is documented in the README: https://github.com/groue/GRDB.swift/blob/master/README.md#encryption. To sum up: people have to fork GRDB.

There is the pull request #1853 which is a follow-up of the previous point. To sum up: people can use a ready-made GRDB fork.

Finally, be ready to witness a lot of struggle: #1827 (TL;DR).

I can answer questions, but honestly I've lost so much time on this already that I am not seeing much interest in rehashing this painful saga. And I have no patience for suggestions like using swift-toolchain-sqlite which is documented to NOT be a general purpose SQLite, or for disabling SQLite snapshots. The solution for people who need to tune GRDB for their personal use, without consideration for other users, is to fork.