Hello, I am trying to include decimal.c in the compiled binary and having it enabled by default. I am able to get it into the amalgation and compile successfully, however, when I try and use the decimal functions, SQLite is still saying "no such function".

I read through the documents, and it seems like I may need to add a call to sqlite3_auto_extension from within sqlite3_decimal_init.

Using vfsstat as a reference, I think I'll need something similar to the below which gets called from sqlite3_decimal_init. However, I don't see an equivalent DecimalModule that I could use to pass in, so I'm not sure what is supposed to go there instead. Unfortunately C is not my strong suit, so I'm not really able to follow what the documentation is suggesting. Any help would be much appreciated!

Thanks

static int vstatRegister(
  sqlite3 *db,
  char **pzErrMsg,
  const sqlite3_api_routines *pThunk
){
  return sqlite3_create_module(db, "vfsstat", &VfsStatModule, 0);
}

Append decimal.c to the amalgamation source. The same goes for any extension you want to be part of the amalgamation.

Append the following code after that:

int core_init(const char* dummy)
{
    int nErr = 0;

    nErr += sqlite3_auto_extension((void*)sqlite3_decimal_init);
    // repeat above for any other extensions you append and want to init on each connection
    return nErr ? SQLITE_ERROR : SQLITE_OK;
}

Then compile the amalgamation with -DSQLITE_EXTRA_INIT=core_init (the preprocessor symbol SQLITE_EXTRA_INIT set to the name of the extra init function above).

On SQLite3 initialization, AFTER all the builtin stuff is initialized, the function defined by the SQLITE_EXTRA_INIT will be called. Similarly, when the library is shutdown a function defined by SQLITE_EXTRA_SHUTDOWN will be called before the rest of the library shutdown. This is to allow you to add stuffs to be initialized on startup and released on shutdown.

this worked perfectly, thank you!

You either need (a) an export (.def) file with all the exports in it included in the compile/link so the linker knows what to export; or, (b) to compile with SQLITE_API=__declspec(dllexport) in order to mark the SQLite3 API functions as exports ...

I did run a test on a Windows 10 64 bit VM before my original reply back here and didn’t notice any issues. I am doing this as a fork of xerial/sqlite-jdbc and don’t see that compile flag in the makefile. I’ll try adding it and see if it makes a difference

You only need that flag if you want to annotate the API symbols with the dllexport flag so that you do not have to use a .def file to tell the linker which global symbols to export.

By default on unix/linux all visible global symbols are exported in discontiguous saved segments.

By default on Windows nothing is exported from discontiguous saved segments.

You can tell the linkers on Windows which global symbols to export by either (a) including a .def file in the input to the linker or (b) marking the global symbols for export in the object file.

If a .def file is presented to the linker then any directives it contains override the same class of directive in the object files. That is, if the .def file specifies EXPORTS then those exports override all exports defined in all object files. If the .def file includes special segment flags, then those flags override the specification of the segment flags embedded in the object files.

Interesting..I am doing this as a fork of xerial/sqlite-jdbc and I ran a quick test on a Windows 10 64bit VM before reporting back here and everything seemed fine. I’ll have to dig deeper and see if I need to make any changes

Using SQLITE_EXTRA_INIT is a bad idea.

in https://sqlite.org/forum/info/e9e218e1ee6355e0 it says about SQLITE_EXTRA_INIT

Because, if it is documented, we have to support it. As it stands currently, we are free to change or remove it as we see fit.

Just as SQLITE_HAS_CODEC it can be removed at any moment

quoted from https://sqlite.org/forum/forumpost/08481b3fac

Unfortunately, SQLITE_HAS_CODEC was never a documented or supported interface.

Is there a better alternative?

I don't know if it is better as such ...

When I tried to integrate some extensions in the amalgamation I looked how extensions like FTS5 and JSON1 where already included and I basically copied that solution.

Search for "An array of pointers to extension initializer functions" and look at the code above and below.

And finally include the extension(s) at the end of the amalgamtion (modify entry and remove superfluous code). One caveat: some extensions don't play nice together - for example when they define indentical functions.