SQLite Forum

sqlite header and source version mismatch
Login
> 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.