Building

There are a number of different ways to build SQLite, depending on what you’re trying to build and where you would like it installed. If you are trying to integrate the SQLite core into a host application, the easiest way to do that is to simply copy sqlite3.c and sqlite3.h into your application’s source directory. If you’re using an IDE, the sqlite3.c file can simply be added to your application’s project file and configured with the proper search paths and build directives. If you want to build a custom version of the SQLite library or sqlite3 utility, it is also easy to do that by hand.

All of the SQLite source is written in C. It cannot be compiled by a C++ compiler. If you’re getting errors related to structure definitions, chances are you’re using a C++ compiler. Make sure you use a vanilla C compiler.

Configure

If you’re using the Unix amalgamation distribution, you can build and install SQLite using the standard configure script. After downloading the distribution, it is fairly easy to unpack, configure, and build the source:

$ tar xzf sqlite-amalgamation-3.x.x.tar.gz
$ cd sqlite-3.x.x
$ ./configure
  [...]
$ make

By default, this will build the SQLite core into both static and dynamic libraries. It will also build the sqlite3 utility. These will be built with many of the extra features (such as full text search and R*Tree support) enabled. Once this finishes, the command make install will install these files, along with the header files and sqlite3 manual page. By default, everything is installed into /usr/local, although this can be changed by giving a --prefix=/path/to/install option to configure. Issue the command configure --help for information on other build options.

Manually

Because the main SQLite amalgamation consists of only two source files and two header files, it is extremely simple to build by hand. For example, to build the sqlite3 shell on Linux, or most other Unix systems:

$ cc -o sqlite3 shell.c sqlite3.c -ldl -lpthread

The additional libraries are needed to support dynamic linking and threads. Mac OS X includes those libraries in the standard system group, so no additional libraries are required when building for Mac OS X:

$ cc -o sqlite3 shell.c sqlite3.c

The commands are very similar on Windows, using the Visual Studio C compiler from the command-line:

> cl /Fesqlite3 shell.c sqlite3.c

This will build both the SQLite core and the shell into one application. That means the resulting sqlite3 executable will not require an installed library in order to operate.

If you want to build things with one of the optional modules installed, you need to define the appropriate compiler directives. This shows how to build things on Unix with the FTS3 (full text search) extension enabled:

$ cc -DSQLITE_ENABLE_FTS3 -o sqlite3 shell.c sqlite3.c -ldl -lpthread

Or, on Windows:

> cl /Fesqlite3 /DSQLITE_ENABLE_FTS3 shell.c sqlite3.c

Building the SQLite core into a dynamic library is a bit more complex. We need to build the object file, then build the library using that object file. If you’ve already built the sqlite3 utility, and have an sqlite3.o (or .obj) file, you can skip the first step. First, in Linux and most Unix systems:

$ cc -c sqlite3.c
$ ld -shared -o libsqlite3.so sqlite3.o

Some versions of Linux may also require the -fPIC option when compiling.

Mac OS X uses a slightly different dynamic library format, so the command to build it is slightly different. It also needs the standard C library to be explicitly linked:

$ cc -c sqlite3.c
$ ld -dylib -o libsqlite3.dylib sqlite3.o -lc

And finally, building a Windows DLL (which requires the sqlite3.def file):

> cl /c sqlite3.c
> link /dll /out:sqlite3.dll /def:sqlite3.def sqlite3.obj

You may need to edit the sqlite3.def file to add or remove functions, depending on which compiler directives are used.

Build Customization

The SQLite core is aware of a great number of compiler directives. Appendix A covers all of these in detail. Many are used to alter the standard default values, or to adjust some of the maximum sizes and limits. Compiler directives are also used to enable or disable specific features and extensions. There are several dozen directives in all.

The default build, without any specific directives, will work well enough for a wide variety of applications. However, if your application requires one of the extensions, or has specific performance concerns, there may be some ways to tune the build. Many of the parameters can also be adjusted at runtime, so a recompile may not always be necessary, but it can make development more convenient.