Following the hints provided here:

• I obtained the source
• Trying To compile on Windows using MSVC, a command similar to the following will usually work:

cl YourCode.c -link -dll -out:YourCode.dll

I am running this from the command prompt:

"D:\Program Files (x86)\Microsoft Visual Studio\2019\EnterpriseSDK\ScopeCppSDK\vc15\VC\bin\cl.exe" FILEIO.c -link -dll -out:FILEIO.dll

My Command prompt is at the directory where FILEIO.C is saved; the location contains just the file FILEIO.C

I am getting this error:

fatal error C1034: ?.h: no include path set

Where ? = one file name or another.

I have made NO changes to FILEIO.C. t seems to fulfil the requirements 4. Programming Loadable Extensions.

I'd appreciate some help in overcoming fatal error C1034; thank you.

I copied sqlite3ext.h & sqlite3.h to the location where fileio.c is.

Now, I'm getting this error:

fatal error C1083: Cannot open include file: 'test_windirent.h': No such file or directory

Compiling is not as straight forward as made out here.

That file is in src/, the same place you got the previous two files from.

Alternately, from an unpacked copy of the SQLite source tree, this might work:

 C:\PATH\TO\SQLITE\SOURCE> cl ext/misc/fileio.c -Isrc -link -dll -out:fileio.dll

Compiling is not as straight forward as made out here.

True. I am about to add an expando-tip to that "usually works" claim. It's author and I are not accustomed to using computers which do not have a compiler, linker, library manipulator, debugger, symbol table dumper, and other tools available with a few keystrokes at a command line shell. So read "usually" as "usually for the supposed target audience."

Given that tool setup described in post #2, fileio.c is still not going to build as easily as described in Compiling A Loadable Extension. This is unusual because fileio.c, when built for WIN32, has (apparently) been designed to link against a semi-public API of the SQLite library. (See sqlite3_win32_utf8_to_unicode if curious.)

To build a standalone DLL for WIN32, this code can be used:

/* utf8_to_wide.c . Fixup for SQLite project's ext/misc/fileio.c extension which appears to require static linking with the SQLite library to get one function that is unavailable otherwise and reuse several of that library's functions which are available from the C runtime. This wrapper provides the said unavailable function and #define's the others to use C runtime versions. This allows the extension to be built and used as a DLL. . Build thusly on Windows using the MSVC development tool set: CL -Os utf8_to_wide.c -link -dll -out:fileio.dll . In addition to this file, these 3 project sources are required: https://www.sqlite.org/src/file?name=ext/misc/fileio.c&ci=trunk https://www.sqlite.org/src/file?name=src/test_windirent.c&ci=trunk https://www.sqlite.org/src/file?name=src/test_windirent.h&ci=trunk */ #undef sqlite3_win32_utf8_to_unicode #define sqlite3_win32_utf8_to_unicode utf8_to_utf16 #include "fileio.c" /* Replacement for SQLite library API: */ LPWSTR utf8_to_utf16(const char *z){ int nAllot = MultiByteToWideChar(CP_UTF8, 0, z, -1, NULL, 0); LPWSTR rv = malloc(nAllot * sizeof(WCHAR)); if( rv!=0 && 0 < MultiByteToWideChar(CP_UTF8, 0, z, -1, rv, nAllot) ) return rv; free(rv); return 0; } #undef sqlite3_malloc #define sqlite3_malloc malloc #undef sqlite3_free #define sqlite3_free free #undef sqlite3_stricmp #define sqlite3_stricmp stricmp #include "test_windirent.c"

After saving the above as utf8_to_wide.c in some directory, and placing sqlite3.h, sqlite3ext.h and the 3 above-referenced sources in that same directory, see its heading comment for the one-liner build invocation.

Thank you for re-visiting this; sharing your insight is much appreciated.

Attempt 1:

CL -Os utf8_to_wide.c -link -dll -out:fileio.dll

And that takes me straight to the

fatal error C1034: ??.h: no include path set

Finding each *.h file and copying to the location where I have FILEIO.C & other files will take a long time.

Attempt 2:

I created a DLL project in VS2019. I feel that I am nearer to compiling FILEIO.C successfully but not quite there yet. Here's the output:

Rebuild started...
------ Rebuild All started: Project: FILEIO, Configuration: Release x64 ------
FILEIO.C
test_windirent.c
utf8_to_wide.c
Generating Code...
utf8_to_wide.obj : error LNK2005: closedir already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: opendir already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: readdir already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: readdir_r already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: sqlite3_fileio_init already defined in FILEIO.obj
utf8_to_wide.obj : error LNK2005: windirent_getenv already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: sqlite3_api already defined in FILEIO.obj
   Creating library E:\SQLite_The Hospital\FILEIO\x64\Release\FILEIO.lib and object E:\SQLite_The Hospital\FILEIO\x64\Release\FILEIO.exp
LINK : fatal error LNK1561: entry point must be defined
Done building project "FILEIO.vcxproj" -- FAILED.
------ Rebuild All started: Project: FILEIO, Configuration: Debug x64 ------
FILEIO.C
test_windirent.c
utf8_to_wide.c
Generating Code...
utf8_to_wide.obj : error LNK2005: closedir already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: opendir already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: readdir already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: readdir_r already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: sqlite3_fileio_init already defined in FILEIO.obj
utf8_to_wide.obj : error LNK2005: windirent_getenv already defined in test_windirent.obj
utf8_to_wide.obj : error LNK2005: sqlite3_api already defined in FILEIO.obj
   Creating library E:\SQLite_The Hospital\FILEIO\x64\Debug\FILEIO.lib and object E:\SQLite_The Hospital\FILEIO\x64\Debug\FILEIO.exp
FILEIO.obj : error LNK2019: unresolved external symbol sqlite3_win32_utf8_to_unicode referenced in function statTimesToUtc
test_windirent.obj : error LNK2019: unresolved external symbol sqlite3_malloc referenced in function opendir
test_windirent.obj : error LNK2019: unresolved external symbol sqlite3_free referenced in function closedir
test_windirent.obj : error LNK2019: unresolved external symbol sqlite3_stricmp referenced in function opendir
E:\SQLite_The Hospital\FILEIO\x64\Debug\FILEIO.dll : fatal error LNK1120: 4 unresolved externals
Done building project "FILEIO.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 2 failed, 0 skipped ==========

Attempt 1: ...
fatal error C1034: ??.h: no include path set

The single-line, compile/link invocation works if my advice in post 2 is followed. Without that environment variable setup, the CL.exe compile/link driver does not know where to find system include files and libraries unless they are (tediously and laboriously) specified at each tool invocation. (Avoidance of the tedium and labor, and the study needed to perform it, is why the batch files and shortcuts to them exist.)

Attempt 2: ...
... error LNK2005: ... already defined in ...

The post in which I embedded utf8_to_wide.c advised this build method: Build thusly on Windows using the MSVC development tool set: CL -Os utf8_to_wide.c -link -dll -out:fileio.dll . Note that a single translation unit is compiled. A glance at that code shows that it #include's a couple of other sources directly. If you additionally compile those and attempt to link the resulting object files, you are bound to get multiple-definition errors.

If you really want to use your IDE to individually compile the C sources and link the results, you will need to do at least this to utf8_to_wide.c: (1) Remove the #include lines which incorporate fileio.c and test_windirent.c into the same compilation; and (2) Add one or more #include lines to bring in headers that fileio.c had itself #include'd. Then you will need to set preprocessor symbols for each of the 3 translation units equivalently to what utf8_to_wide.c had arranged as it caused them all to be compiled. (There may be a single set of values that works for all 3, or they may have to differ; I don't know.)

Now I must say something that might seem unkind (but is not:) If you are intent on being a software developer, you must learn to read and understand error messages that come from the tools you use. Bringing each little tool complaint to a forum where other participants are willing and able to do that is not a workable approach. A web search for the portions of error messages not specific to your project(s) may be illuminating as you initially learn what they mean. But the errors that have appeared in your threads here are very fundamental -- so much so that you should be making your own effort to discover what they mean. That is how you will progress up the learning curve.

I kept the faith knowing that the detailed instructions would have been tested successfully and persevered. Several hours later I have created FILEIO.DLL

20/09/2021 14:43 148,992 fileio.dll

Larry, I'd be interested to know how the size compares with the size of your FILEIO.DLL.

I have tested this extension and no longer get the aberration I reported The steps I followed are:

Step 1 Start Command Prompt as Administrator

Step 2 Find the location of CL.EXE; the location should have the dependencies mspd*.DLL. In my case, this location is: cd "D:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC14.29.30133\bin\Hostx86\x86" That is, I have to be in this directory.

Step 3 Find the batch file that creates the environment wherein CL.EXE can find the *.h dependencies. In my case this batch file is: "D:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCAuxiliaryBuildvcvars32.bat" I ran this batch file which provided this response:

[vcvarsall.bat] Environment initialized for: 'x86'

Step 4

cl -Os "E:SQLite_The HospitalFILEIOutf8_to_wide.c" -link -dll -out:fileio.dll

This provided this feedback:

Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30133 for x86 Copyright (C) Microsoft Corporation. All rights reserved.

utf8_to_wide.c Microsoft (R) Incremental Linker Version 14.29.30133.0 Copyright (C) Microsoft Corporation. All rights reserved.

/out:utf8_to_wide.exe -dll -out:fileio.dll utf8_to_wide.obj Creating library fileio.lib and object fileio.exp

Step 5 Since "D:\Program Files (x86)\Microsoft Visual Studio\2019Enterprise\VC\Tools\MSVC\14.29.30133\bin\Hostx86\x86" is a system location (the reason for running as Administrator) , I need to tidy up.

• Deleted utf8_to_wide.obj
• Copied FILEIO.DLL to another (preferred) location
• Deleted FILEIO.*

Step 6 Tested FILEIO.DLL from my preferred location with success.

Hopefully, this experience will save me (& others) time when compiling other extensions.

Larry, thank you very much..

I'm just responding to a few minor issues, quoted.

[reporting file size] 148,992 fileio.dll
Larry, I'd be interested to know how the size compares with the size of your FILEIO.DLL.

I get your size with latest VS2019 compiler targeting x86 and 178688 bytes targeting amd64.

Step 1 Start Command Prompt as Administrator

That is not necessary. Ordinary privilege is all that is needed.

Step 2 ... Step 3 ...

There is a VS2019 (and earlier) installation option to provide Start menu shortcuts that accomplish all that with two clicks and some mouse motion.

... need to tidy up ... Deleted FILEIO.*

It is odd to delete fileio.c and no other sources.

... Tested FILEIO.DLL from my preferred location with success.

I was unable to discover how that fileio.dll you found was built when I perused the site where you were told to find it. This makes me wonder what it really was.

Hopefully, this experience will save me (& others) time when compiling other extensions.

Most (or maybe all) other extensions are as easy to build as is suggested at Compiling a Loadable Extension.

I will ponder how to warn about the extra considerations for fileio.c when built for WIN32.

thank you

You're welcome. We intend that this is somewhat easier than you experienced.

It is odd to delete fileio.c and no other sources.

I have kept ALL the source files ... which are in a location (E:\SQLite_The Hospital\FILEIO\) other than where fileio.dll is created (D:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\Hostx86\x86)

I have checked in a revised fileio.c which better accomplishes the effect of the separate source I posted earlier in this thread.

The fileio.dll extension can now be built thusly: CL -Os -DFILEIO_WIN32_DLL fileio.c -link -dll -out:fileio.dll , (assuming that a suitable vc_vars??.bat is run first as discussed earlier.) It is still necessary to have test_windirent.c, test_windirent.h, sqlite3ext.h and sqlite3.h in the same directory as fileio.c (or made #include'able via CL.exe's -I option.)

I would appreciate it if you could use that source to build and verify satisfactory operation of the fileio extension.^a Please post results, positive or otherwise. (And consider it payback for the technical help.)

---

a. The resulting image has a slight improvement: The extension code which traffics in heap allocated objects with the SQLite library will use the same allocator that has been used by default or designated for the library's use via sqlite3_config. This defaults to malloc() and its cohorts, so this improvement will usually have no effect.

• Repeated the compilation with the new FILEIO.C. Passed. DLL is the same size as with the previous method of compilation.
• Repeated my tests with the new FILEIO.DLL. Passed.

I noticed that the new FILEIO.C has the same date, namely, 2014-06-13. Should this change?

Repeated the compilation with the new FILEIO.C. Passed. DLL is the same size as with the previous method of compilation.

For clarity, I used the CL syntax given i.e.

CL -Os -DFILEIO_WIN32_DLL fileio.c -link -dll -out:fileio.dll

Repeated the compilation with the new FILEIO.C. Passed. DLL is the same size as with the previous method of compilation.

Without FILEIO_WIN32_DLL defined, the preprocessed code is unchanged substantively. (Only whitespace and #line directives will differ.) So only debug builds could differ in size.

Repeated my tests with the new FILEIO.DLL. [(using -DFILEIO_WIN32_DLL)] Passed.

Thanks for verifying (and for the CL options carification.)

I noticed that the new FILEIO.C has the same date, namely, 2014-06-13. Should this change?

The headings of files in the repository are left alone as the source evolves.

There are 3 NEW blocks of code in the new version, namely, lines [75] - [79], [232] - [247], [1002] - [1030] ... made the difference between compiling success and failure.

Thanks for sorting it out.

I'm curious: why aren't compiled extensions not included in the downloads? Especially FILEIO.DLL as it is built-in SQLite3.EXE but omitted in SQLite3.DLL.

Thanks for sorting it out.

It either needed fixing or an apologetic/caution against using it like the other extensions in just one context. Fixing won.

I'm curious: why aren't compiled extensions ... included in the downloads? Especially FILEIO.DLL as it is built-in SQLite3.EXE but omitted in SQLite3.DLL.

The SQLite library is the main, supported product here. That is what is made conveniently available at the download page.

SQLite.exe and SQLite.dll differ more than how they are (normally) loaded. The former is the CLI shell, an application which uses and is linked against the library. The latter is just the library. There is much in the shell, including other extensions, that is not compiled into the dropped library images.

The extensions tend to be much more stable than the library and the shell. And they have less usage (I surmise.) So it is not evident that publishing binaries for the extension set across the supported platforms is worth the extra clutter on the download page and extra work required to create them. This could change some day, but nobody should hold their breath until then.

Include the directory containing the needed .h files on the command line. For example, if the "sexyturd.h" file is required and it can be found in directory "D:/Toilet" then add that include directory to your command:

-ID:/Toilet

Lather rinse and repeat adding each directory which contains an include file that the compiler needs to locate.