Hi,
I tried your suggestion, and cross-compiled dynamic lsqlite3.so to use dynamic libsqlite3.so and liblua.so. Which makes C++ and LUA using the same sqlite3 library instance and that solved the WAL problem apparently. Could you please help me with updating the original ticket? I've submitted the ticket as anonymous due to problems with registration on lua.sqlite3.org and I'm not familiar with the interface of LuaSQLite3 ticket system. Not sure how to answer to the same thread as anonymous.
The ticket:
https://lua.sqlite.org/index.cgi/tktview/0c4a8253ac
On Thu, 2 Sept 2021 at 07:54, Семёнов Дмитрий <d-kei@yandex.ru> wrote:
Stack: android 7 (fs ext4) - JNI (NDK 21.4.7075529) - c++ 11 - sqlite 3.27.2 - lua 5.3.4 - lsqlite3complete 0.9.5
Hi,
Any specific reason to use lsqlite3complete? If I understand
correctly, you're running two different versions of SQLite on the same
process (3.27.2 from C++ and 3.24 from lsqlite3complete).
Even if SQLite has very high forward file compatiblity between
versions, there's no guarantee that you can go forward and backwards
repeatedly and during an open transaction. It's probably worse when
they share the same process and thus might share file descriptors,
signals, and other kernel interface entities.
Much safer would be to use the same SQLite library for both C++ and
Lua. I'm no expert on Android packaging, but in most cases there's a
way to make it simply visible to lsqlite3. If you're using shared
libraries, it might just work. If you're compiling statically, some
linker flags could keep the SQLite symbols exported.
(copied from my answer to the ticket)
--
Javier
