Unable to compile spellfix extension of latest tarball that uses "SQLITE_VTAB_INNOCUOUS"
(1) By Isofruit on 2021-07-04 08:21:49 [link] [source]
Heyho everybody,
I wanted to try out spellfix for a hobby project of mine. I'm not terribly familiar with C/C++ and compiling my own code, which is likely why I ran into this issue. Seeing as spellfix is a loadable extension, I figured that I would need to compile that C file into an .SO file and then somehow load it (Using: Linux - Ubuntu).
The problem I ran into is that the usual commands around the internet do not seem to work for me for the latest downloadable tarball (Here a SO Question of somebody with a similar issue:). The commands I found were these:
wget
tar xzf sqlite.tar.gz
mkdir sqlitebld
gcc -shared -fPIC -Wall -I. sqlite/ext/misc/spellfix.c -o sqlitebld/spellfix.so
However, that failed with the error:
~/dev$ gcc -shared -fPIC -Wall -I. sqlite/ext/misc/spellfix.c -o sqlitebld2/spellfix.so
sqlite/ext/misc/spellfix.c: In function ‘spellfix1Init’:
sqlite/ext/misc/spellfix.c:2072:31: error: ‘SQLITE_VTAB_INNOCUOUS’ undeclared (first use in this function); did you mean ‘SQLITE_STATIC’?
sqlite3_vtab_config(db, SQLITE_VTAB_INNOCUOUS); ^~~~~~~~~~~~~~~~~~~~~ SQLITE_STATIC
In a last ditch effort I tried out this SO answer that targeted what I assume to be a specific release (3110100):
wget
unzip sqlite-src-3110100.zip
gcc -shared -fPIC -Wall -Isqlite-src-3110100 sqlite-src-3110100/ext /misc/spellfix.c -o spellfix.so
This one did compile.
Looking at the 3110100 spellfix.c file, that seems to be because the words "SQLITE_VTAB_INNOCUOUS" are not being used here. I assume this is about some kind of vtab feature that maybe hadn't been implemented back then? Now I'll assume that under normal circumstances the up-to-date version of spellfix.c would compile and my machine is missing something to do so properly. My question would be what is missing/required here so that I can use an up-to-date version of spellfix?
(2.1) By Keith Medcalf (kmedcalf) on 2021-07-04 10:21:44 edited from 2.0 in reply to 1 [source]
You didn't tell the compiler the location of the .h files that are to be used during the compile.
The spellfix.c file references
#include "sqlite3ext.h" which in turn
#include <sqlite3.h>, and the version of sqlite3.h that is being used belongs to some older version of sqlite3 that does not define the pre-processor symbol SQLITE_VTAB_INNOCUOUS.
The 3.11.1 code is old enough that it does not require that the header files you are using define the symbol SQLITE_VTAB_INNOCUOUS because that security feature was implemented after that version.
(3) By Larry Brasfield (larrybr) on 2021-07-04 10:32:46 in reply to 1 [link] [source]
I'm not terribly familiar with C/C++ and compiling my own code, which is likely why I ran into this issue.
Perusing Compiling A Loadable Extension should help with that.
[Saw error] sqlite/ext/misc/spellfix.c:2072:31: error: ‘SQLITE_VTAB_INNOCUOUS’ undeclared (first use in this function); did you mean ‘SQLITE_STATIC’?
... This one did compile.
Your are encountering a problem with extension code and SQLite library code which are at different points along the project's evolution. If you just use spellfix.c and sqlite3.h from the same (or sufficiently similar) source snapshots, the "undeclared" complaints should vanish.
(4.1) By Isofruit on 2021-07-04 12:19:02 edited from 4.0 in reply to 3 [link] [source]
Alrighty. I think I've got it down with that. From the SQLITE section I gather for the most part, that the command to use is:
gcc -g -fPIC -shared YourCode.c -o YourCode.so
I also gather so far from your and Keith Medcalf's posts that the key is the proper sqlite3.h file. That file wasn't there by default, but only gets created after "make"-ing the tarball, correct?
So the order of actions is:
Get tarball (which also contains the spellfix.c file), unpack it and make it, you now have 2 dirs, the "unzipped tarball-folder" (for me: sqlite) and the "sqlite build-folder" (for me: sqlitebld), the latter containing the sqlite3.h file
copy over the /ext/misc/spellfix.c file from sqlite to sqlitebld so that the spellfix.c file can find the sqlite3.h file (the compiler implicitly assumes h files are in the same directory as the file being compiled I think?)
Run the above command to compile spellfix itself
That compiled the spellfix.c file without a screaming error message at least. I think this was the correct way? My lack of compiling experience is what's giving me uncertainty here. My expectation was that I'd have a .so file flying about after building the tarball, as opposed to doing a second compile step for the spellfix.c file with the build sqlite tarball.
(5) By Larry Brasfield (larrybr) on 2021-07-04 13:59:48 in reply to 4.1 [link] [source]
You probably should read How To Compile SQLite. If, after sections 1 and 4 leave you still wanting to build your own amalgamation, you should read Building The Amalgamation From Canonical Source Code. On *nix systems, you will be running a "configure" script before expecting make to do the right thing.
(6) By Isofruit on 2021-07-06 18:43:31 in reply to 5 [link] [source]
Alright, I've gotten so far that I can compile sqlite3 and spellfix.so and can load spellfix.so in the sqlite3-CLI.
Question on my end to make sure I didn't overlook anything: This is how it was intended and designed, correct? Compile a core sqlite3 installation that can load extensions, compile the extension separately, then during runtime use .load in the CLI or one of the various other means to load said extension and then use it.
That is at least what I have understood from all the things I've read so far and what I could manage to get to work. Is that the correct way to do it?
(7) By Larry Brasfield (larrybr) on 2021-07-06 19:01:16 in reply to 6 [link] [source]
Alright, I've gotten so far that I can compile sqlite3 and spellfix.so and can load spellfix.so in the sqlite3-CLI.
Congrats.
... This is how it was intended and designed, correct? Compile a core sqlite3 installation that can load extensions, compile the extension separately, then during runtime use .load in the CLI or one of the various other means to load said extension and then use it.
That does describe anticipated usage of the SQLite CLI shell source and the shell once built. That's the scenario we want to docs to support well.
... Is that the correct way to do it?
Not sure about "correct", or what rules determine that. If you built per the docs guiding that, and the result is useful to you, that has to be counted in the success column. I can say you are not off in the woods by yourself.