Missing include in wal.c breaks --enable-amalgamation=no build
(1) By anonymous on 2024-05-30 11:55:07 [source]
Hello,
I tried building sqlite3 for WebAssembly with --enable-amalgamation=no and encountered a build issue (default builds work fine):
/projects/sqlite/repo/bld/../src/wal.c:747:3: error: must use 'struct' tag to refer to type 'Wal'
747 | Wal *pWal, /* The WAL context */
[...]
The underlying issue seems to be a mismatch between SQLITE_OMIT_WAL as checked at the beginning of wal.c and in some parts of wal.h. Due to platform constraints SQLITE_OMIT_WAL should be set for WASM builds but this is only picked up halfway through the include chain. Adding #include "sqlite3.h" to the beginning of wal.c fixed the issue, though I'm not sure if this is the correct fix.
Thanks!
(2) By Stephan Beal (stephan) on 2024-05-30 12:53:33 in reply to 1 [link] [source]
Due to platform constraints SQLITE_OMIT_WAL should be set for WASM builds
It is set so explicitly in our WASM builds, as it's not supported there.
We don't currently know of a 100% reliable way to determine, at compile time, "this is a WASM build" in the core library, so don't disable it there.
The workaround is to explicitly disable WAL in your build.
(3) By anonymous on 2024-05-30 13:05:49 in reply to 2 [link] [source]
It looks like WAL is disabled unconditionally for this type of build (WASM w/ WASI):
https://github.com/sqlite/sqlite/blob/5b7048d5af1ec22371bb1f57556548f9724903c3/src/sqlite.h.in#L10836
This define just doesn't make it to the start of wal.c for non-amalgamation builds.
(5) By Stephan Beal (stephan) on 2024-05-30 18:50:25 in reply to 3 [link] [source]
It looks like WAL is disabled unconditionally for this type of build (WASM w/ WASI):
Please try with the latest trunk, where the explicit SQLITE_OMIT_WAL has been removed. You may need to pass that flag to your WASI build, though.
(6) By anonymous on 2024-05-30 21:48:10 in reply to 5 [link] [source]
Yep, this fixes the discrepancy between amalgamation and non-amalgamation builds.
The change regresses WASI builds though (configure --with-wasi-sdk=X), so some additional logic in the configure script would be great to have. :)
Thanks!
(7) By Stephan Beal (stephan) on 2024-05-30 21:52:59 in reply to 6 [link] [source]
The change regresses WASI builds though (configure --with-wasi-sdk=X), so some additional logic in the configure script would be great to have. :)
We don't touch the autotools bits unless absolutely necessary, and what would even need touching isn't even remotely clear.
Given the regression, i am going to roll back that change.
Is there are particular reason you're trying to build wasm from the canonical sources instead of the amalgamation?
(8) By anonymous on 2024-05-30 22:44:17 in reply to 7 [link] [source]
Is there are particular reason you're trying to build wasm from the canonical sources instead of the amalgamation?
Not really. I hit a "can't handle files with over X lines" type issue with Sentry Source Bundles and this was the first thing I tried. The "split amalgamation" build might be the way to go here, or I'll stick with disabling amalgamation and explicitly passing SQLITE_OMIT_WAL.
(4) By Nuno Cruces (ncruces) on 2024-05-30 13:19:42 in reply to 2 [link] [source]
Actually, about that, could you have a look at:
www:/forum/forumpost/4ab1e8985828334f342232f35935e564bd3c416e9571447d22f907767786f6e5