SQLite User Forum

sqlite3.h
Login

sqlite3.h

(1) By Chris Moore (Chrismoore) on 2022-07-21 01:18:09 [link] [source]

All

I can get Visual Studio to pick up <sqlite3.h> from my #include statement in my C++ program, but the Powershell and Command prompt window where I can run "cl" to compile C++ programs cannot find the same <sqlite3.h>. its in the same folder as the C++ program itself. I also cannot get the Dev C++ compiler to find it either. If I change or add #include "sqlite3.h" the command prompt and Dev C++ compilers seem to find it but then start complaining about my System namespace - as if it was unloaded or blown out of memory. I sometimes have the same problem with sqlite3.dll too. Any ideas on how to fix this?

sqllite3 is working great with Visual Studio C++. I even moved the exe to my desktop and put sqlite3.dll in my desktop folder too and it runs great.

(2) By Larry Brasfield (larrybr) on 2022-07-21 01:39:17 in reply to 1 [link] [source]

"cl" to compile C++ programs cannot find the same <sqlite3.h>. its in the same folder as the C++ program itself.

You need to add to the CL.exe invocation another option, "-I<sqlite_dir>", where "<sqlite_dir>" is replaced by the path to the directory where sqlite3.h resides.

You might find it useful to run "CL.exe /help" and peruse the output sometime.

... I sometimes have the same problem with sqlite3.dll too.

No, you do not. DLLs are located for loading according to an entirely separate set of rules than those by which CL.exe locates #include targets. You can look them up with a simple web search. That could have led to this.

(3) By anonymous on 2022-07-21 03:09:14 in reply to 2 [source]

The above reply was painful to read.

Suggest changing "You might find it useful to run "CL.exe /help" and peruse the output sometime"

to something along the lines of "CL.exe /help output has the relevant information".

And suggest changing

"DLLs are located for loading according to an entirely separate set of rules than those by which CL.exe locates #include targets"

to something less extreme (due to some of the 'rules' being universal, eg. file actually existing somewhere) such as

" DLLs are located for loading according to a different set of rules than those by which CL.exe locates #include targets".

And one last clean-up could be changing

"You can look them up with a simple web search. That could have led to this"

to something less abrasive. A less derogatory approach might be

"The dynamic link library search order is documented here" (with the hyperlink).

On occasion I find reading through the forum unnecessarily painful, and as a result, less useful than it could be without the jibes. Unless there is some compelling reason I suggest at least considering taking the edge off.

If anyone is interested in how to get there, one technique is just taking the time to re-read from the perspective to the recipient, and editing anything that one would not like to be on the other end of.

It could make the world a better place.

(4) By Chris Moore (Chrismoore) on 2022-07-30 01:38:40 in reply to 1 [link] [source]

Yes, adding the -I<directory? option to the CL line and putting a few Sqlite objects in the same directory as my cpp source member solved all the Sqlite compile and runtime issues.

Adding an -I<directory> option for the Windows Reference Assembly fixed my namespace System issue as well.

I was also trying to compile under Dev C++ (it uses the gcc compiler) but Dev C++ does not like Windows Reference Assemblies at all. They claim to be incompatible with Visual Studio C++. But that's for another forum. I may try to remove the variable references to System and see if it will compile otherwise - Dev C++ seemed to have no issues with the Sqlite includes.

Thank for the help!

(5) By Keith Medcalf (kmedcalf) on 2022-07-30 17:19:42 in reply to 4 [link] [source]

Files that are #include <filename> search for the file in the (system) include path directories and do not look anywhere else at all. This list of directories may be specified in the INCLUDE environment variable or otherwise magically defined by the compiler itself.

Files that are #include "filename" are expected to be in the current directory. The (system) include (and directories listed in the INCLUDE environment variable) are not searched.

You may "append" a directory to the include path by adding -I <directory> to the compiler command tail. Such a direcdtory will be appended to the directories in the (system) include path for the purpose of locating #include <filename> files. If the filename specified in #include "filename" is not found in the current directory the any appended (-I) directories will be searched.

Similarly, libraries can be specified either directly or via -l stem. Such libraries are looked for first in the current directory, and then in the (system) library path. This list of directories may be specified in the LIB environment variable or otherwise magically defined by the compiler itself.

Directories to be searched for link libraries may be specified (and are appended to the search order) by appending -L directory to the compiler command tail.

This has been the way of things since about 1966.

There are a number of places that are searched by the Operating System when it is looking for files. Some are magical, most are specified in environment variables. Examples are PATH (for executables), PATHEXT (the list of executable extensions), LIBPATH, and a few others.

(6) By Chris Moore (Chrismoore) on 2022-07-30 21:52:05 in reply to 4 [link] [source]

For Dev C++ I was able to just replace Console::WriteLine lines with cout to get past the Windows Reference Assemblies issue. But then I received the dreaded "undefined reference" error on my sqlite functions. But it wasn't a "not found" or "cant open" issue. This suggested a problem with the linker (and not the compiler). So I worked on making sure the linker was looking in the right place.

I have found much of the C++ and associated documentation in digital documentation, on websites, and in books to be very lacking. gcc is no different. Real examples work best for me. I copied the folder sqlite to sqlite3 in case some header file had the sqlite3 hardcoded somewhere. Here is the exact command lines that worked for me.

Compiler

-I"C:sqlite3" -L"C:sqlite3"

Linker

-static-libgcc -lsqlite3 -lsqlite3-64

** Note for the linker command line: those are small cap "L's" after the dashes. And NO quotes around the file names, no folder/directory/path in the file names, and no .lib at the end of the filenames. These are the actual file names without the .lib. The folder/directory/path for libraries is handled in the Compiler argument L above.

(7) By Stephan Beal (stephan) on 2022-07-30 22:02:49 in reply to 6 [link] [source]

This suggested a problem with the linker (and not the compiler). So I worked on making sure the linker was looking in the right place.

...

-static-libgcc -lsqlite3 -lsqlite3-64

For std::cout support, among other things, you'll want -lstdc++.