Status: Exploratory

SQLite was originally designed to be an embedded database for on-board guided missile destroyers, for the US Navy The Definitive Guide to Sqlite By Michael Owens. Unlike many database program, SQLite is designed to be an itegral part of the embedded system. SQLite doesn't use interprocess communication, which makes it much faster than a database system that does.

Porting SQLite to RTEMS

This is a very rough first stab at porting SQLite to RTEMS. It's designed to help a developer that might be interested in designing the RTEMS_DBKit...

Note: there is room to port a stable release...

I also used the RTEMS Addon Packages to get the necessary configurations to build on rtems.

Development Repository Editon SQLite

To build SQLite from the development repository, you need TCL and fossil. TCL is part of the SQLite build system, while fossil is another version control system.

~$ sudo apt-get install tcl8.5 fossil

SQLite uses fossil for their development branch, so if you use their development branch, you have some steps to go through:

First, check out a "fossil" which is a single file with all the information

~/rtems-addon-packages$ fossil clone trunk.fossil

Second, make and navigate into an sqlite directory:

~/rtems-addon-packages$ mkdir sqlite ~/rtems-addon-packages$ cd sqlite

Third, open the fossil file

~/rtems-addon-packages/sqlite$ fossil open ../trunk.fossil

Fourth, archive the sqlite folder (so you have an old copy to fall back on)...

~/rtems-addon-packages/sqlite$ cd .. ~/rtems-addon-packages$ tar -acf sqlite.fossil.tar.bz2 sqlite

DO NOT close the fossil file! It will remove manifest.uuid and not compile!


Just figured out how to get SQLite to compile! First, the sqlite command shell executable may NOT be necessary, which bypasses the need to figure out how to implement popen and pclose. To NOT build the command shell executable, I looked at the Makefile, and built the non sqlite3 make targets. Namely, lib_intall, and the sqlite3.h.

To avoid sys/mman.h dependency, I looked for sys/mman.h

$ grep -r "sys\/mman.h" rtems-addon-packages/sqlite

and found that defining SQLITE_OMIT_WAL would eliminate the mmap/munmap dependency.

I copied the Makefile below into rtems-addon-packages/RTEMS_Makefiles/Makefile.sqlite

# Configure/build/install the sqlite library
# -DSQLITE_OMIT_WAL removes mman dependency
# --disable-largefile makes a library for a 32-bit target on a 64-bit host
# --disable-amalgamation keeps the source code in separate files for the build
# copy the public header to the include directory
# finally, install the library

include ../RTEMS_Makefiles/Makefile.common

	../sqlite/configure \
		--prefix=$(exec_prefix) \
		--build=i686-linux-gnu \
		--host=i386-rtems4.11 \
		--disable-largefile \
		--enable-cross-thread-connections \
		--disable-tcl \
		--disable-readline \
		--disable-amalgamation \
		--libdir=$(exec_prefix)/$(RTEMS_BSP)/lib \
	make sqlite3.h
	cp sqlite3.h $(exec_prefix)/$(RTEMS_BSP)/lib/include
	make lib_install

Another option is to comment out all the references to handle pipes in sqlite/src/shell.c then, make && make install.

If you spot a linker error claiming unresolved symbol 'utimes', you can easily solve it by defining the following (anywhere in your code):

int utimes(const char *filename, const struct timeval times[2])

    return 0;

Using the configuration above with RTEMS 4.10.2, SQLite, pc386 BSP, reveals that "in-memory" databases works amazingly well. However, you may experience "I/O disk failure" with persistent database on msdos partitions. Probably, a new RTEMS-specific VFS (Virtual File System, in SQLite jargon) must to be implemented using low-level open/read/write/close directives.

The increase of the image size (compiled with -O2 -g) is quite big:

.TEXT: +482KiB

.DATA: +3KiB

.BSS: +1KiB

Further investigation in progress.


When adding commands to a shell from a legacy library: # Link the library to EVERY application using the shell # Write a script to tear down and rebuild the kit, and use it at every small change

rtems-addon-packages/network-demos$ nano

make clean make qemu ...

Linking libraries (please see OpenLDAP on

Testing Ideas

# Link the SQLite library using a Makefile. # Use An Introduction To The SQLite C/C++ Interface as a guideline for the test. So the idea would be to: # Open the database # Prepare the SQL statement for processing # "Step" through the results, in this case, an insert (or make table?) would be awesome! # Some simple column statement # Finalize (delete) the prepared statement # Close the connection.

Therefore, an example of what test MAY include code similar to...

 /* ==================== SQL Test ================== */
 /* Database initialization */
 printk("Opening the Database\n");
 sqlite3_open(filename, &ppDb, flags, &zVfs);
 printk("Preparing the SQL Statement\n");
 sqlite3_prepare_v2(&db, &zSql, nByte, &ppStmt, &pzTail);
 printk("Stepping through the Results\n");
 printk("Counting the number of columns...");
 nCols = sqlite3_column_count(&ppStmt);
 printk("and the number of columns is %d\n", nCols);
 printk("Deleting the SQL Statement\n");
 printk("Closing the Database");

Next Steps

# Write an SQLite demo # Work on other database programs in the RTEMS_DBKit # See if a database connection over a network on RTEMS is feasible

End of Report

I'm truly amazed that SQLite had configurations that removed the multiprocessing, and memory mapping requirements!

= References =

Last modified on Jan 27, 2015 at 12:20:10 AM Last modified on Jan 27, 2015, 12:20:10 AM