Try either of these fixes:

1. Rename your entry point to have only lower case.

2. In your sqlite3_load_extension call, provide the entry point you have.

Just because you told your C++ compiler does not affect the C++ "name mangling" done by C++ compilers. Suggest you use DUMPBIN (or whatever tool you want to use) to look at the export table for the DLL. It is probably exporting the name mangled all to ratshit (in the C++ fashion).

The exported name should be "sqlite3_sqlitefcts_init" to match the name of the dll file.

If the name is mangled to ratshit in the C++ fashion (ie, not the above) try declaring it a cdecl as in:

__declspec(dllexport) cdecl int sqlite3_sqliteFcts_init

I compile your code thusly:

cl -nologo -W4 -DINCLUDE_MSVC_H=1   -DSQLITE_OS_WIN=1 -I. -I. -fp:precise -MT -DNDEBUG -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_TEMP_STORE=1  -DSQLITE_MAX_TRIGGER_DEPTH=100 -DSQLITE_ENABLE_FTS4=1 -DSQLITE_ENABLE_FTS5=1 -DSQLITE_ENABLE_JSON1=1 -DSQLITE_ENABLE_RTREE=1 -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DEFAULT_FOREIGN_KEYS=1 -DSQLITE_ENABLE_SESSION=1 -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_PREUPDATE_HOOK=1 -DSQLITE_INTROSPECTION_PRAGMAS -DSQLITE_ENABLE_EXPLAIN_COMMENTS -DSQLITE_ENABLE_STMTVTAB -DSQLITE_ENABLE_DBPAGE_VTAB -DSQLITE_ENABLE_DBSTAT_VTAB -DSQLITE_ENABLE_UNKNOWN_SQL_FUNCTION -DSQLITE3_OMIT_WINDOWFUNC -O2  -DSQLITE_API=__declspec(dllimport) -LD sqliteFcts.c

Then I had the following session:

> sqlite3m
SQLite version 3.32.0 2020-02-18 19:49:48 (with modified shell)
Enter ".help [<command>]" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .load sqliteFcts sqlite3_sqliteFcts_init
sqlite> .q

> sqlite3m
SQLite version 3.32.0 2020-02-18 19:49:48 (with modified shell)
Enter ".help [<command>]" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .load sqliteFcts
Error: The specified procedure could not be found.

sqlite> .q

> notepad ..\sqliteFcts.c

After changing the entry point to 'sqlite3_sqlitefcts_init' (note case change), I compiled again, the same way, and had the following session:

> sqlite3m
SQLite version 3.32.0 2020-02-18 19:49:48 (with modified shell)
Enter ".help [<command>]" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .load sqliteFcts
sqlite> .q

I don't know what you are doing differently. As far as I can tell, if you build the DLL with the usual calling convention and export, it should work with the entry point renamed or with it explicitly specified to sqlite3_load_extension(). Perhaps you are not linking correctly to the sqlite3 API. See the last -D argument to CL.exe about that.

DUMPBIN is a part of many Windows SDKs. DEPENDS.EXE (Dependancy Walker) can also show you dependancies and import/export names. https://www.dependencywalker.com/

I hope that I have not led your attention too far astray with that voluminous compiler invocation. I use it to compile extensions which do a bit more than yours, and make use of the SQLite API to do so. The SQLITE_API qualifier is used to denote SQLite library entry points that are exposed, outside of the library itself, so that clients can call into the API by means of references that are resolved at link time. In this case, the linkage is into a dynamic load library, with linkages resolved at DLL load time. In that context, '__declspec(dllimport)' means 'create a reference (or address) to be resolved when the client code loads and either loads (or finds already loaded) the SQLite library as a DLL. By convention, extensions do not rely on linkage resolved that way; instead, they get a struct passed into them which contains all the API function addresses already resolved before the extension is loaded. If your extension works that way, (once it is made to actually do something), you will not need that particular define.

It has been too long since I used clang for me to opine usefully on what it is complaining about. However, I can suggest that looking at the preprocessed form of your code can be very helpful when setting out to cure that sort of problem.

If my posts on this have any relevance, it is to show that your problem lies in linkage issues rather than some mysterious failure of sqlite3_load_extension() to load a DLL and attempt to find the entry point it is given or must deduce as a default. As you can see, that works per that API's documentation.

FWIW, I second Keith's recommendation that you use dumpbin.exe to sort out what has happened. With that tool, it is easy to see what names have actually been defined and compare those to the names reflecting to-be-resolved-at-link references. In addition to possible (but unlikely IMO) C versus C++ name decoration issues, you may be suffering from decoration variation with calling convention. Keywords to lookup on that are CDECL and STDCALL.

If you were to change the 'F' in your init function's name to 'f', then it would not be necessary to provide the entry point to sqlite3_load_extension().

For several years, since Microsoft introduced Delay-loaded DLLs, the dependency walker has shown "errors" associated with references to such DLLs. They can generally be ignored. You can recognize them, and justify ignoring them, from the fact that the dependency tree shows them as called into by one (or more) DLL(s) that you did not create. Your germane concern is with unsatisfied references from any DLL you have created.

Yeah, those API-MS-... and MS-EXT-... are how Microsoft implements "interfaces" in Windows 10. They are not really DLLs at all. They can be ignored. Anything that is compiled to run on Windows 10 will have a crap load of them. If you target exclusively an earlier version of Windows, they will all go away.

If a DLL is missing and it is NOT one of these "interface" dlls, then it is a "real" error as opposed to just a fake error because the dependancy walker does not properly ignore these "interfaces".

I don't know why your compiler is mangling the names, but at least now you know what it is doing.

You could define redefine SQLITE_EXTENSION_INIT1 after the first include.

The reason that these work when appended to the sqlite3.c (the amalgamation) is that it (sqlite3.c) has the symbol SQLITE_CORE defined which indicates that the sqlite3 API is to be called directly rather than via the "global array of indirect pointers" created by the SQLITE_EXTENSION_INIT1 macro (and initialized by the SQLITE_EXTENSION_INIT2 macro), thus those macro's expand to /* no-op */ and do nothing.

Since you can only declare a global once, you can only execute the SQLITE3_EXTENSION_INIT1 macro once per compilation unit.

#include "eval.c"
#undef SQLITE_EXTENSION_INIT1
#define SQLITE_EXTENSION_INIT1 /* no-op */
#include "carray.c"
... etc ...

You could probably make it look nicer (easier to maintain in the future) by doing something like this:

#include <sqlite3ext.h>

SQLITE_EXTENSION_INIT1

#undef SQLITE_EXTENSION_INIT1
#define SQLITE_EXTENSION_INIT1 /* no-op* /

#include "eval.c"
#include "carray.c"
#include "series.c"
#include "btreeinfo.c"

#ifdef _WIN32
__declspec(dllexport)
#endif

int sqlite3_whatever_init(
  sqlite3 *db,
  char **pzErrMsg,
  const sqlite3_api_routines *pApi
){
  SQLITE_EXTENSION_INIT2(pApi);
  if ((rc = sqlite3_eval_init(db, pzErrMsg, pApi)) == SQLITE_OK)
  if ((rc = sqlite3_carray_init(db, pzErrMsg, pApi)) == SQLITE_OK)
  if ((rc = sqlite3_series_init(db, pzErrMsg, pApi)) == SQLITE_OK)
  if ((rc = sqlite3_btreeinfo_init(db, pzErrMsg, pApi)) == SQLITE_OK)
  ;
  return rc;
}

To make it clear that SQLITE_EXTENSION_INIT1 is only called once and ignored in the included files, and provide an init function for the entire DLL ...