*: CodeWarrior: Notes on compiling on MacOS using CodeWarrior If the "configure" script does not work for you, then you might have to compile manually. Fortunately, this is easy to do. First download the preprocessed source code from http://www.sqlite.org/sqlite_source.zip. This archive contains a set of C source and header files that are ready to be passed to a C compiler. To build the library, just compile all of the files. Note that the files "shell.c" and "tclsqlite.c" are special and do not belong in the SQLite library proper. "shell.c" is used to build the "sqlite" shell program and "tclsqlite.c" is the TCL bindings for SQLite. You may want to omit both of these files when you build the library. For example, I was able to compile SQLite for HPUX as follows: unzip sqlite_source.zip rm tclsqlite.c for i in *.c; do c89 -O -c $i; done rm shell.o ar cr libsqlite.a *.o ranlib libsqlite.a c89 -o sqlite shell.c libsqlite.a ==== DJGPP (DOS) libsqlite.a and sqlite.exe may be made for djgpp in a similar way as above. it compiles and works out of the box, with the following limitations: 1. temporary files are not removed upon database close (journal file). 2. files created by sqlite automatically will be correctly created only if lfn is enabled. otherwise, lacking the journal file, the database will be open read-only. my diffs are fixing both problems, and make sqlite work very well on djgpp. to avoid overload of this page, i have attached patches to sqlite development tickets. each patch applies for a certain sqlite version, as follows: for sqlite 2.8.6: diff attached at http://www.sqlite.org/cvstrac/tktview?tn=524 for sqlite 2.8.11: diff attached at http://www.sqlite.org/cvstrac/tktview?tn=572 for sqlite 2.8.13: diff attached at http://www.sqlite.org/cvstrac/tktview?tn=717 it will also do no harm to incorporate it in the main sqlite distribution. ==== beneath there is another djgpp listing, the functionality of which has been already applied in mainstream sqlite, in a macro that ignores fnctl calls. in my opinion, it is not needed to apply anymore. To get it compiling on DJGPP (DOS) you need to patch src/os.c with the following (unified diff): --- ../temp/sqlite/src/os.c 2002-10-20 20:16:50.000000000 +0000 +++ src/os.c 2002-12-24 18:31:16.000000000 +0000 @@ -27,6 +27,10 @@ # include #endif +#if (!defined __DJGPP__) && (!defined O_BINARY) +#define O_BINARY 0 +#endif + /* ** Macros for performance tracing. Normally turned off */ @@ -232,9 +236,9 @@ int *pReadonly ){ #if OS_UNIX - id->fd = open(zFilename, O_RDWR|O_CREAT, 0644); + id->fd = open(zFilename, O_RDWR|O_CREAT|O_BINARY, 0644); if( id->fd<0 ){ - id->fd = open(zFilename, O_RDONLY); + id->fd = open(zFilename, O_RDONLY|O_BINARY); if( id->fd<0 ){ return SQLITE_CANTOPEN; } @@ -306,7 +310,7 @@ #ifndef O_NOFOLLOW # define O_NOFOLLOW 0 #endif - id->fd = open(zFilename, O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW, 0600); + id->fd = open(zFilename, O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_BINARY, 0600); if( id->fd<0 ){ return SQLITE_CANTOPEN; } @@ -359,7 +363,7 @@ */ int sqliteOsOpenReadOnly(const char *zFilename, OsFile *id){ #if OS_UNIX - id->fd = open(zFilename, O_RDONLY); + id->fd = open(zFilename, O_RDONLY|O_BINARY); if( id->fd<0 ){ return SQLITE_CANTOPEN; } @@ -682,9 +686,13 @@ lock.l_type = F_RDLCK; lock.l_whence = SEEK_SET; lock.l_start = lock.l_len = 0L; +#ifdef __DJGPP__ + { +#else if( fcntl(id->fd, F_SETLK, &lock)!=0 ){ rc = SQLITE_BUSY; }else{ +#endif rc = SQLITE_OK; id->pLock->cnt = 1; id->locked = 1; @@ -736,9 +744,13 @@ lock.l_type = F_WRLCK; lock.l_whence = SEEK_SET; lock.l_start = lock.l_len = 0L; +#ifdef __DJGPP__ + { +#else if( fcntl(id->fd, F_SETLK, &lock)!=0 ){ rc = SQLITE_BUSY; }else{ +#endif rc = SQLITE_OK; id->pLock->cnt = -1; id->locked = 1; @@ -798,9 +810,13 @@ lock.l_type = F_UNLCK; lock.l_whence = SEEK_SET; lock.l_start = lock.l_len = 0L; +#ifdef __DJGPP__ + { +#else if( fcntl(id->fd, F_SETLK, &lock)!=0 ){ rc = SQLITE_BUSY; }else{ +#endif rc = SQLITE_OK; id->pLock->cnt = 0; } This is needed, because files need to be explicitely opened in binary mode and the check for locking always fails in DJGPP. DJGPP: http://www.delorie.com/djgpp ==== *Microsoft Visual Studio.NET* See HowToCompileWithVsNet. ==== *MSVC and SQLite DLL* Creation of an import library from the sqlitedll.zip (http://www.sqlite.org/sqlitedll.zip) for MS Visual C++ is achieved by the following command: LIB /DEF:sqlite.def This makes the files sqlite.lib and sqlite.exp files. The sqlite.lib can then be used to link your programs against the SQLite DLL. ===== *Crosscompile linux x86 -> linux arm* 1. Install skiff toolchain or similar, make shure you have arm-linux-gcc in your PATH. 2. Unpack sqlite sources and create a directory _sqlite-arm_ in the same dir. 3. Edit _configure_ script in the sqlite dir and comment following lines out as shown - have fun finding them ;-) if test "$cross_compiling" = "yes"; then { { echo "$as_me:12710: error: unable to find a compiler for building build tools" >&5 echo "$as_me: error: unable to find a compiler for building build tools" >&2;} { (exit 1); exit 1; }; } fi . . . else test "$cross_compiling" = yes && { { echo "$as_me:13264: error: cannot check for file existence when cross compiling" >&5 echo "$as_me: error: cannot check for file existence when cross compiling" >&2;} { (exit 1); exit 1; }; } . . . else test "$cross_compiling" = yes && { { echo "$as_me:13464: error: cannot check for file existence when cross compiling" >&5 echo "$as_me: error: cannot check for file existence when cross compiling" >&2;} { (exit 1); exit 1; }; } . . . else test "$cross_compiling" = yes && { { echo "$as_me:13490: error: cannot check for file existence when cross compiling" >&5 echo "$as_me: error: cannot check for file existence when cross compiling" >&2;} { (exit 1); exit 1; }; } 4. Save the configure script, change into the build directory you created and call the edited configure script from the sqlite directory by using the following option: ../sqlite/configure --host=arm-linux 5. After that configure should have created a Makefile and a libtool script in your build directory. Open the Makefile using your favorite text editor and edit the following line: BCC = arm-linux-gcc -g -O2 to see: BCC = gcc -g -O2 6. run _make_ Now you should find a ".libs" directory in your build directory containing sqlite shared object files, like libsqlite.so. Source (somewhat altered): http://www.kecher.de/howtos/SQLite-JDBC-Howto.html ===== *Win32 recompile with mingw32/msys* good as of sqlite source 2.8.13. 1. Download mingw from www.mingw.org 2. Download msys from www.mingw.org 3. Install mingw to c:\mingw and msys to c:\msys N.B.! Need to override msys installer's default to install in c:\mingw DO NOT co-mingle msys binaries with mingw's -- see: http://www.mingw.org/mingwfaq.shtml#faq-usingwithmsys 4. Download the FULL sqlite source (http://www.sqlite.org) and extract it to desired location (e.g., c:\....\mysqlite) 5. start the msys.bat (in c:\msys), which opens msys shell window, and cd to sqlite source location. Invoke msys's ./configure. 6. call mingw32-make to compile the resulting Makefile. (make isn't used anymore - see http://www.mingw.org/mingwfaq.shtml#faq-mingw32-make.exe) 7. Find within the source distribution a file called sqlite.def which contains EXPORTS sqlite_open sqlite_close sqlite_exec sqlite_last_insert_rowid sqlite_error_string sqlite_interrupt sqlite_complete sqlite_busy_handler sqlite_busy_timeout sqlite_get_table sqlite_free_table sqlite_mprintf sqlite_vmprintf sqlite_exec_printf sqlite_exec_vprintf sqlite_get_table_printf sqlite_get_table_vprintf sqlite_freemem sqlite_libversion sqlite_libencoding sqlite_changes sqlite_create_function sqlite_create_aggregate sqlite_function_type sqlite_user_data sqlite_aggregate_context sqlite_aggregate_count sqlite_set_result_string sqlite_set_result_int sqlite_set_result_double sqlite_set_result_error sqliteMalloc sqliteFree sqliteRealloc sqlite_set_authorizer sqlite_trace sqlite_compile sqlite_step sqlite_finalize 8. dllwrap --dllname sqlite.dll --def sqlite.def *.o (or if this doesn't work, dllwrap --def sqlite.def -v --export-all --driver-name gcc --dlltool-name dlltool --as as --target i386-mingw32 -dllname sqlite.dll -lmsvcrt *.o) 9. strip sqlite.dll 10. Ready. ==== *Win32 recompile with borland c++ builder* 1. Download preprocessed source from http://www.sqlite.org/sqlite_source.zip 2. Unzip the source to a project directory, e.g. C:\sqlite 3. Fire up your borland c++ builder and create a new dll project, plain C without mfc or something like that 4. Save the project as (e.g.) C:\sqlite\sqlite.bpr 5. Add the sqlite source files from c:\sqlite to the project 6. Remove the unit1.* files from your project 7. Even if .def files are not the clean way, it will be easier than rewriting the sourcecode. Create the file sqlite.def with the following content and add it to the project: LIBRARY sqlite.dll EXPORTS sqlite_open = _sqlite_open sqlite_close = _sqlite_close sqlite_exec = _sqlite_exec sqlite_last_insert_rowid = _sqlite_last_insert_rowid sqlite_error_string = _sqlite_error_string sqlite_interrupt = _sqlite_interrupt sqlite_complete = _sqlite_complete sqlite_busy_handler = _sqlite_busy_handler sqlite_busy_timeout = _sqlite_busy_timeout sqlite_get_table = _sqlite_get_table sqlite_free_table = _sqlite_free_table sqlite_mprintf = _sqlite_mprintf sqlite_vmprintf = _sqlite_vmprintf sqlite_exec_printf = _sqlite_exec_printf sqlite_exec_vprintf = _sqlite_exec_vprintf sqlite_get_table_printf = _sqlite_get_table_printf sqlite_get_table_vprintf = _sqlite_get_table_vprintf sqlite_freemem = _sqlite_freemem sqlite_libversion = _sqlite_libversion sqlite_libencoding = _sqlite_libencoding sqlite_changes = _sqlite_changes sqlite_create_function = _sqlite_create_function sqlite_create_aggregate = _sqlite_create_aggregate sqlite_function_type = _sqlite_function_type sqlite_user_data = _sqlite_user_data sqlite_aggregate_context = _sqlite_aggregate_context sqlite_aggregate_count = _sqlite_aggregate_count sqlite_set_result_string = _sqlite_set_result_string sqlite_set_result_int = _sqlite_set_result_int sqlite_set_result_double = _sqlite_set_result_double sqlite_set_result_error = _sqlite_set_result_error sqliteMalloc = _sqliteMalloc sqliteFree = _sqliteFree sqliteRealloc = _sqliteRealloc sqlite_set_authorizer = _sqlite_set_authorizer sqlite_trace = _sqlite_trace sqlite_compile = _sqlite_compile sqlite_step = _sqlite_step sqlite_finalize = _sqlite_finalize 8. Go to Project|Options|Directories/Conditionals. Add 'NO_TCL' to Conditional defines 9. Fire up the compiler. 10. Ready. ==== *Mac OS X build* I used the standard Unix build instructions... $ tar xzf sqlite.tar.gz Unpacks into directory named "sqlite" $ mkdir bld Create a separate build directory $ cd bld $ ../sqlite/configure --disable-shared $ make Builds "sqlite" and "libsqlite.a" $ make test Optional: run regression tests *But* don't forget the implied $ make install step! The --disable-shared option is required for Mac OS X because libtool is busted and will generate an invalid shared library. The usability of the sqlite shell is greatly enhanced if you have readline support. If you install GNU readline first, sqlite will link to it automatically. ==== Under AIX 4.3.3 with gcc fmedico yahoo.com mkdir sqlite cd sqlite unzip ../sqlite_source.zip rm tclsqlite.c libsqlite.a sqlite 2> /dev/null for i in *.c; do gcc -g -O2 -c $i; done rm shell.o ar cr libsqlite.a *.o ranlib libsqlite.a gcc -o sqlite shell.c libsqlite.a ==== *Cygwin* 1. Run configure 2. edit src/os.h, go to ~ line 90 (behind the #ifndef OS_UNIX block) and add ala mingw solution above #define OS_WIN 1 #define OS_MAC 0 #define OS_UNIX 0 A similar change has already been checked into the CVS tree and should appear with release 2.8.6. In 2.8.13 an extra slash passed to libtool caused me some trouble installing on cygwin. Removing each occurance of $(DESTDIR)/ from Makefile did the trick. There were eight, all in the install section. This var is handy for distributions, so probably don't want to remove. ==== *Boost.Jam* This assumes you're a C++ type who likes http://boost.org Haven't gotten into the tcl interface, so the C_SOURCES variable bears inspection. Acquire boost, and boost jam. Navigate to /libs mkdir sqlite cd sqlite mkdir src mkdir build cd src cd ../build # (C) Copyright 2002. Permission to copy, use, modify, sell and # distribute this software is granted provided this copyright notice appears # in all copies. This software is provided "as is" without express or implied # warranty, and with no claim as to its suitability for any purpose. # # # Boost.sqlite build # # To run all tests quietly: jam test # # Declares the following targets: # 1. sqlite, a library to be linked with all # Boost.sqlite modules # # declare the location of this subproject relative to the root subproject libs/sqlite/build ; # Base names of the source files for libboost_sqlite C_SOURCES = attach auth btree btree_rb build copy delete expr func hash insert main opcodes os pager parse pragma printf random select table tokenize trigger vdbe where update util vacuum ; EXE_ONLY = shell ; dll sqlite : ../src/$(C_SOURCES).c : $(BOOST_ROOT) : debug release ; lib sqlite : ../src/$(C_SOURCES).c : $(BOOST_ROOT) : debug release ; exe sqlite : ../src/$(C_SOURCES).c ../src/$(EXE_ONLY).c : $(BOOST_ROOT) : debug release ; Now you can just build sqlite along with the rest of boost. Tested on VC7.1 and GCC 3.3.1. Boost jam builds debug, release, static, and dynamically linked targets with a lack of fuss and bother. ==== *AIX 5.2 with large file support* I used the IBM compiler _xlc_ with specific cflags to build SQLite 2.8.7. AIX uses a slightly different define to enable 64 bit I/O in the system headers *_LARGE_FILES*. SQLite expects *_LARGE_FILE*, so I define both flags. The final two flags are *-q32* which builds as a 32 bit application and *-qlonglong*, which enables the _long long_ datatype. Here are the steps I used: ./configure edit Makefile, change the TCC macro: TCC = xlc -q32 -qlonglong -D_LARGE_FILE=1 -D_LARGE_FILES=1 -DUSE_TCL_STUBS=1 -O2 -DOS_UNIX=1 -DOS_WIN=0 -DHAVE_USLEEP=1 -I. -I${TOP}/src make Tom Poindexter 2003-12-17 ==== *Building a statically linked libtclsqlite* I use SQLite as part of a Starkit-based application. See http://equi4.com/tclkit.html and http://equi4.com/starkit.html In assembling a Starkit for Linux, one problem is incompatibility between different verions of glibc (e.g. RedHat 7.2 using glibc2.2, RedHat 8.0 using glibc2.3). There is a static build of tclkit for linux that avoids this problem by statically linking all libraries. I wanted the SQLite extension for Tcl to have the same feature. Here are steps to build a statically linked Tcl extension: First, make sure that the -DUSE_TCL_STUBS=1 macro is defined in your TCC makefile macro. We will be linking manually, so if using gcc, get the path to the libgcc.a for your installation: gcclib=`gcc -print-libgcc-file-name` Add the following lines to your SQLite Makefile: echo '' >>Makefile echo 'static-libtclsqlite.so: tclsqlite.lo $(LIBOBJ)' >>Makefile echo " ld -shared -soname libtclsqlite.so -o libtclsqlite.so *.o -L/usr/local/lib -ltclstub8.4 -static -ldl -lm -lc $gcclib" >>Makefile Note that a tab should be inserted a the first character of the second line. Adjust your path to your Tcl install if not /usr/local/lib in order to find libtclstub8.4.a. Now build: make make static-libtclsqlite.so Tom Poindexter 2003-12-17 ==== **[ ULTRIX/VAX 4.4 ]** I successfully got Sqlite 2.8.13 to compile under ULTRIX/VAX 4.4 (4.x should work fine, not sure about earlier versions). SQLite would NOT compile with VAX C, I had to install GCC and GNU make. There are binary packages out there for GCC 3.0.4 and GNU MAKE floating around on the net. After setting the CC and CPP environment variables to the location of GCC (in my case it was /usr/freeware/gnu-tools/vax/bin/gcc) and the preprocessor, SQLite compiled out of the box, just run configure, then GNU make (stock BSD make will NOT work!) and it will chew on it for a couple hours (hey, it's still a VAX), and in theory you should have working Ultrix SQLite. NOTE: Remember, Ultrix has no support for shared libraries, if you want to use SQLite in an application, you have to compile sqlite in as a static library. This goes for TCL as well, you have to recompile TCL with libsqlite.la and libtclsqlite.la compiled smack inline. No, I don't have any benchmarks unfortunately. It would be funny to benchmark SQLite against the University Ingres QUEL DBMS that ships with Ultrix on the UNSUPPORTED software distribution on the CD/TK50 tape/whatever else Ultrix shipped on. My configuration: DEC VAXserver 3100 m30 w/ 16MB/RAM, 1.6GB disk space. ULTRIX 4.4/VAX GCC 3.0.4 GNU MAKE Have fun. Kevin D. Ogden 19 APR 2004 E-Mail: ogdenk REPLACE-WITH-CORRECT-CHARACTER expressautoservice.com