SQLite User Forum

sqlite header and source version mismatch
Login
Hierarchical

sqlite header and source version mismatch

(1) By Mauricio InfosecInkari (mauricioseis) on 2021-06-24 02:50:09 [link] [source]

eam,

when I try to access the daily.db i nsqlite3 and having this error:

SQLite header and source version mismatch 2018-12-01 12:34:55 bf8c1b2b7a5960c282e543b9c293686dccff272512d08865f4600fb58238alt1 2013-10-17 12:57:35 c78be6d786c19073b3a6730dfe3fb1be54f5657a

Centos 8.2.2004 core

Any help would be appreciated

(2) By Warren Young (wyoung) on 2021-06-24 08:07:02 in reply to 1 [link] [source]

2018-12-01 corresponds to the SQLite 3.26 included with CentOS 8. This means you're picking up the system version of sqlite3.h and linking it to SQLite 3.8.1 from 2013-10-17.

Is there a good reason why you're not building entirely against either the system version or something newer?

Regardless, it's unsafe to mix versions of the header and library. Thus the error. It's trying to save you from doing something likely to lead to unhappy outcomes.

(3) By Mauricio InfosecInkari (mauricioseis) on 2021-06-24 12:58:05 in reply to 2 [link] [source]

Hi Warren and thanks for the prompt answer,

This is an application which was upgraded and I believe the sqlite3 was o properly updated. What to do?

(4) By Keith Medcalf (kmedcalf) on 2021-06-24 13:58:35 in reply to 1 [link] [source]

It has nothing whatsoever to do with the database being accessed.

The message means that the version of the sqlite3 shell program being executed was built so as to use the "system shared library", and that the "system shared library" being loaded is a "different version" of the code than the version of the code that was used to build that sqlite3 shell program.

In other words, there is more than one "package" of sqlite3 stuffs on your computer and they do not represent the same version of sqlite3.

The version of the "system shared library" is 2018-12-01 12:34:55 bf8c1b2b7a5960c282e543b9c293686dccff272512d08865f4600fb58238alt1
but the version of the sqlite3 CLI application is 2013-10-17 12:57:35 c78be6d786c19073b3a6730dfe3fb1be54f5657a

You need to use the package manager for your OS to upgrade (or downgrade) one or the other components so the are the same or otherwise make them consistent (perhaps by downloading and compiling the current version).

Although the version mismatch is for the most part immaterial, the sqlite3 shell program complains about the difference because use of a diagnostic tool in an inconsistent state might result in inconsistent and irreproducible results.

(5) By Warren Young (wyoung) on 2021-06-24 17:54:12 in reply to 3 [source]

I believe the sqlite3 was properly updated.

Clearly not.

What to do?

First, observe that you do in fact have multiple copies of SQLite on that system. I can tell that just from your report, but you can prove it to yourself with commands like "locate sqlite3". (That's assuming mlocate is installed and its updatedb service is running: systemctl status mlocate-updatedb.timer)

Next, decide how to cope with this reality. You have three basic choices:

  1. Keep using this 3.8.1 version for whatever obscure reason you have. Beware that you can expect less help here if you insist on using software from 2013.

  2. Switch to the system SQLite (3.26) from 2018, which is at least "supported" in the sense that Red Hat backports security and serious bug fixes back to it from current versions, and those updates are then rebuilt by the CentOS project and redistributed. You may still get some push-back here when asking for help with this version, since the fix for whatever problem you may have may be in a later version of SQLite.

  3. Upgrade to a current version of SQLite, building it from source rather than using pre-built packages. Not only does this get you all the latest features and any fixes that Red Hat deems not worthy of backporting, it's probably more in line with your software's nature, given that you've demonstrated that it doesn't take option #2 today. Since you've clearly got some mechanism for building SQLite from source — else we wouldn't see evidence of 3.8.1 in use on an OS release that wasn't even in existence in 2013 — you could just update that process and ensure that it doesn't find the system SQLite package's files.

(6) By Mauricio InfosecInkari (mauricioseis) on 2021-06-25 20:02:06 in reply to 5 [link] [source]

Hi Warren,

Well explained.

Regards,

(7) By Mauricio InfosecInkari (mauricioseis) on 2021-06-25 20:02:31 in reply to 4 [link] [source]

Thanks for your explanation and support