SQLite Forum

Compile error when symbols SQLITE_OMIT_SHARED_CACHE and SQLITE_USER_AUTHENTICATION=1 are both defined
Login

Compile error when symbols SQLITE_OMIT_SHARED_CACHE and SQLITE_USER_AUTHENTICATION=1 are both defined

(1) By Aloys (aloys) on 2021-07-22 11:59:01 [source]

If the preprocessor symbol SQLITE_OMIT_SHARED_CACHE is defined, the member nTableLock is not defined in the structure Parse.

If the preprocessor symbol SQLITE_USER_AUTHENTICATION=1 is also defined, the compiler emits an error message for the line

    if( pParse->nTableLock>0 && db->init.busy==0 ){

in function sqlite3FinishCoding (line 112602 in the SQLite amalgamation for version 3.36.0), because the undefined member nTableLock is referenced in this statement.

It would be nice if this issue could be fixed for the next SQLite version.

Thanks in advance.

(2.1) By TripeHound on 2021-07-22 22:06:00 edited from 2.0 in reply to 1 [link] [source]

Are you building from the amalgamation, or the full sources? Some options (including many of the ..._OMIT_... ones) only work when building from the full sources. See Options To Omit Features in the SQLite docs.

(3) By Aloys (aloys) on 2021-07-23 07:36:27 in reply to 2.1 [link] [source]

I'm building from the amalgamation. I'm aware of the fact that not all _OMIT_ options work as expected when building from the amalgamation. However, the option SQLITE_OMIT_SHARED_CACHE has no influence on the lemon-generated parser. Therefore I suppose that building from the amalgamation with this option enabled should work.

In the light of DRH's comment regarding shared cache mode about a year ago I would almost call it good practice to omit shared cache mode.

As far as I can tell using option SQLITE_OMIT_SHARED_CACHE seems to work properly when compiling from the amalgamation.

However, it's not a question of working at runtime. If the combination of the options SQLITE_OMIT_SHARED_CACHE and SQLITE_USER_AUTHENTICATION is used the code does not compile, because the compiler complains about the missing definition for nTableLock (in line 188 of build.c). That is, the problem exists also when building from canonical sources. The reason is simply that the use of the member nTableLock is not guarded by some #ifndef SQLITE_OMIT_SHARED_CACHE preprocessor instruction, as it most likeley should.