sqlite3_open_v2() failed when run with custom build of emsdk@4.0.1

[subframe7536]

In my custom build, I upgrade the emsdk to 4.0.1 and it fails to open db:

[rhashimoto]

@subframe7536 This is odd because result code 8 is SQLITE_READONLY, and to the best of my knowledge no example VFS returns that. Can you tell me what VFS you are using and what arguments are being passed to open_v2()?

[subframe7536]

Sorry for missing reproduction, I test it in my custom wrapper's PR but seems fail to auto backlink here.

All the main code is run with open_v2(path, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE) on chrome 131:

MemoryVFS

TypeError: Cannot mix BigInt and other types, use explicit conversions

IDBBatchAtomicVFS / OPFSAnyContextVFS

WebLocksMixin: unlock error TypeError: Cannot read properties of undefined (reading 'type')
    at _IDBBatchAtomicVFS.jUnlock (WebLocksMixin.js:86:33)
    at _IDBBatchAtomicVFS.jUnlock (IDBBatchAtomicVFS.js:422:18)

sqlite-api.js:861 Uncaught (in promise) SQLiteError: sqlite3_open_v2

Also has check error:

IDBMirrorVFS / OPFSCoopSyncVFS

sqlite-api.js:861 Uncaught (in promise) SQLiteError: sqlite3_open_v2

[rhashimoto]

EMSDK 4.0 changed the default setting of WASM_BIGINT to true. wa-sqlite expects 64-bit ints to be passed as a "legalized" pair of 32-bit numbers so that would cause all kinds of havoc.

Fixed with #241.

[sgbeal]

Roy, in case you haven't seen this yet: emsdk 4.0 indirectly changes the timing of Module.postRun execution. That broke the "official" wasm build and might (might) impact wa-sqlite as well:

emscripten-core/emscripten#23420