bgcolor # Type Status Created By Subsys Changed Assigned Svr Pri Title _Description _Remarks #f2dcdc 2915 build active 2008 Feb pweilbacher 2008 Feb 4 3 fix Makefile for platforms that need .exe extension There are some targets that need a $(TEXE) added in Makefile.in. Otherwise a platform that needs a .exe extension cannot run e.g. tests. #f2dcdc 2909 build active 2008 Jan aswift 2008 Jan aswift 4 4 Omit the _XOPEN_SOURCE 500 define on Mac OS-X (check for __APPLE__) sqliteInt.h attempts to avoid setting _XOPEN_SOURCE on MacOSX by checking if __DARWIN__ is defined, however on Leopard (as of Mac OS X 10.5) this test fails and should be enhanced by testing for both __DARWIN__ and __APPLE__ Building sqlite succeeds with _XOPEN_SOURCE defined, but it causes _POSIX_C_SOURCE to be defined which leads to failing to define F_FULLFSYNC which prevents use of the fullfsync pragma. #c8c8c8 2895 build closed 2008 Jan anonymous 2008 Jan 3 1 Please describe how to run an indvidual test out of the test suite Please describe how to run an individual test out of the test suite? Thanks. For example, how to run the test incrvacuum-ioerr-1.31.4 _2008-Jan-17 17:14:12 by drh:_ {linebreak} Tickets are for reporting bugs, not asking questions about how to compile or operate SQLite. For questions of that nature, please post comments on the SQLite mailing list. See http://www.sqlite.org/support.html. PS: You cannot run individual tests. You have to run an entire script. #c8c8c8 2890 build closed 2008 Jan anonymous 2008 Jan 1 1 Assistance request fixing six 3.5.4 i/o test failures Failures include exclusive-ioerr-2.280.4 exclusive-ioerr-2.281.4 exclusive-ioerr-2.282.4 incrvacuum-ioerr-1.31.4 io-4.1 io-4.2.3 Please let me know how to run individual tests, so I can debug these and submit fix suggestions. Thanks. _2008-Jan-15 21:50:52 by drh:_ {linebreak} These errors do not appear when the tests are run individually. They are only reproducible when you run the complete test suite. ---- _2008-Jan-16 03:15:50 by anonymous:_ {linebreak} Please give an example of how to run one individual test. Thanks. #c8c8c8 2889 build closed 2008 Jan anonymous 2008 Jan 3 2 Cannot disable TCL Slackware 12 TCL/TK is not installed, as I don't need it, and don't really want to install it Sequence of commands to reproduce : tar -xzvf sqlite-3.5.4.tar.gz cd sqlite-3.5.4 mkdir bld cd bld ../configure --disable-tcl --without-tcl make The last command dies with --------------------------------------------------- rm tsrc/sqlite.h.in tsrc/parse.y cp parse.c opcodes.c keywordhash.h tsrc tclsh ../tool/mksqlite3c.tcl make: tclsh: Command not found make: *** [sqlite3.c] Error 127 root@slack12:~/install/sqlite-3.5.4/bld# ls .. --------------------------------------------------- Thanks in advance Roman Same as #2845, #2346, #2871. #f2dcdc 2881 build active 2008 Jan anonymous 2008 Jan 1 1 Latest sqlite-3.5.4 build fail on latest Fedora 2.6.23.12-52.fc7 Two test cases fail. io-4.1... Expected: [3] Got: [2] io-4.2.1... Ok io-4.2.2... Ok io-4.2.3... Expected: [3] Got: [2] io-4.3.1... Ok Let me know how to run individual test cases and how this might be fixed. Here's how I built sqlite using latest CVS. If something is wrong here, let me know and I'll rebuild/retest. I'm building on latest Fedora fc7. Thanks. _______ net1#uname -a Linux net1.coolsurf.com 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 20:27:10 EST 2007 x86_64 x86_64 x86_64 GNU/Linux net1#build_sqlite mkdir -p /build/work/sqlite-3.5.4 cd /build/work/sqlite-3.5.4 unset CDPATH export CFLAGS='-pipe -O3 -g -DSQLITE_DISABLE_DIRSYNC=1 -Wall' rm -rf bld cvs -d :pserver:anonymous@www.sqlite.org:/sqlite -r update . mkdir bld cd bld ../configure --prefix=/common/pkgs/sqlite-3.5.4 --enable-tcl --with-tcl=/usr/lib64 --enable-threadsafe --enable-threads-override-locks make groupadd vuser || /bin/true useradd -M -g vuser -d /vhost/davidfavor.com/users/david -s /bin/zsh david || /bin/true useradd -M -g vuser -d /vhost/livefeast.com/users/yemiah -s /bin/zsh yemiah || /bin/true chown david:vuser -R .. su -c "make test" david _2008-Jan-11 17:18:52 by anonymous:_ {linebreak} Same tests still fail with CVS of today around 11AM CST. ---- _2008-Jan-11 17:41:55 by drh:_ {linebreak} FWIW, both those test cases pass on SuSE 10.1. I do not understand why they are failing on Fedora. But in any event, the tests in question are verifying logic that implements an optimization that is not used on Fedora, ever. So the failures are of no consequence. If those are the only two tests that fail, then you can safely use the build for whatever it is you are trying to do. ---- _2008-Jan-11 19:16:19 by anonymous:_ {linebreak} Failures when 'make fulltest' built with CFLAGS of '-pipe -O3 -g -Wall -DSQLITE_DISABLE_DIRSYNC=1 -DSQLITE_MEMDEBUG' exclusive-malloc-1.transient.746...make: *** [fulltest] Segmentation fault Failures when 'make fulltest' built with CFLAGS of '-pipe -O3 -g -Wall -DSQLITE_DISABLE_DIRSYNC=1' Skipping malloc tests: not compiled with -DSQLITE_MEMDEBUG... 6 errors out of 61998 tests Failures on these tests: exclusive-ioerr-2.280.4 exclusive-ioerr-2.281.4 exclusive-ioerr-2.282.4 incrvacuum-ioerr-1.31.4 io-4.1 io-4.2.3 All memory allocations freed - no leaks Maximum memory usage: 14376554 bytes Pre 3.5.x builds work fine on Fedora. If you're open to debugging all these, I'd like to go through and resolve all these one by one, so Fedora has a clean build/fulltest. Please let me know how to run each test individually and I'll try to figure out the problem with each. Thanks. #c8c8c8 2876 build closed 2008 Jan anonymous 2008 Jan 1 1 3.5.4 fails to build on OpenBSD... $ ./configure --prefix=/home/achowe/Projects/org/sqlite --disable-tcl --enable-threadsafe $ make ... rm tsrc/sqlite.h.in tsrc/parse.y cp parse.c opcodes.c keywordhash.h tsrc tclsh ./tool/mksqlite3c.tcl tclsh: not found *** Error code 1 There appears to be a TCL dependency even though I've specified --disable-tcl. Stock OpenBSD does not supply TCL and I have no desire to install it. Duplicate of ticket #2845. #c8c8c8 2871 build closed 2008 Jan anonymous 2008 Jan 3 3 SQLite 3.5.4 build process does not listen to --disable-tcl I build sqlite without TCL support, with an incantation along the lines of: =../sqlite-3.5.4/configure --disable-tcl; make=. This works fine in 3.5.3 but 3.5.4 fails late in the compilation, looking for =tclsh=: =tclsh ../sqlite-3.5.4/tool/mksqlite3c.tcl= is the command it's trying to run. I'm building on Solaris 10u4 and the full incantation for =configure= is as follows (most of this is for readline): =../sqlite-3.5.4/configure --prefix=/home/tfb/packages/sqlite-3.5.4 --enable-static=no --with-readline-lib="-L/opt/sfw/lib -R/opt/sfw/lib -lreadline -lcurses" --with-readline-inc=-I/opt/sfw/include --disable-tcl=. I use =gmake= (which is GNU make, in =/usr/sfw/bin= on Solaris 10) to compile. This is not urgent for me - I will just stick with 3.5.3 for now - but it would be nice to avoid mandatory dependence on TCL I think. Thanks --tim Duplicate of ticket #2845 #f2dcdc 2866 build active 2008 Jan anonymous 2008 Jan 1 3 Problems building Windows native in cygwin/mingw environment Trying to build Windows native version using the Cygwin build environment. $ gcc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) $ $ CFLAGS=-mno-cygwin ./configure --disable-tcl --enable-threadsafe $ make A) The make appears to build sqlite3.exe just fine, without errors or warnings. This binary does work from cmd.exe, BUT not from within the bash cygwin shell for some reason, unlike other Windows native binaries I've built. Next... $ make install B) The cc sqlite3.c -o sqlite3 fails to rebuild sqlite3.exe correctly with the -mno-cygwin option. The output follows: rm -rf tsrc mkdir -p tsrc cp ./src/alter.c ./src/analyze.c ./src/attach.c ./src/auth.c ./src/btmutex.c ./src/btree.c ./src/btree.h ./src/build.c ./src/callback.c ./src/complete.c ./src/date.c ./src/delete.c ./src/expr.c ./src/func.c ./src/hash.c ./src/hash.h ./src/insert.c ./src/journal.c ./src/legacy.c ./src/loadext.c ./src/main.c ./src/malloc.c ./src/mem1.c ./src/mem2.c ./src/mem3.c ./src/mutex.c ./src/mutex_os2.c ./src/mutex_unix.c ./src/mutex_w32.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pager.h ./src/parse.y ./src/pragma.c ./src/prepare.c ./src/printf.c ./src/random.c ./src/select.c ./src/shell.c ./src/sqlite.h.in ./src/sqliteInt.h ./src/table.c ./src/tclsqlite.c ./src/tokenize.c ./src/trigger.c ./src/utf.c ./src/update.c ./src/util.c ./src/vacuum.c ./src/vdbe.c ./src/vdbe.h ./src/vdbeapi.c ./src/vdbeaux.c ./src/vdbeblob.c ./src/vdbefifo.c ./src/vdbemem.c ./src/vdbeInt.h ./src/vtab.c ./src/where.c ./ext/fts1/fts1.c ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.c ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_porter.c ./ext/fts1/fts1_tokenizer.h ./ext/fts1/fts1_tokenizer1.c sqlite3.h ./src/btree.h ./src/btreeInt.h ./src/hash.h ./src/sqliteLimit.h ./src/mutex.h opcodes.h ./src/os.h ./src/os_common.h ./src/sqlite3ext.h ./src/sqliteInt.h ./src/vdbe.h parse.h ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_tokenizer.h ./src/vdbeInt.h tsrc cp: warning: source file `./src/btree.h' specified more than once cp: warning: source file `./src/hash.h' specified more than once cp: warning: source file `./src/sqliteInt.h' specified more than once cp: warning: source file `./src/vdbe.h' specified more than once cp: warning: source file `./ext/fts1/fts1.h' specified more than once cp: warning: source file `./ext/fts1/fts1_hash.h' specified more than once cp: warning: source file `./ext/fts1/fts1_tokenizer.h' specified more than once cp: warning: source file `./src/vdbeInt.h' specified more than once rm tsrc/sqlite.h.in tsrc/parse.y cp parse.c opcodes.c keywordhash.h tsrc tclsh ./tool/mksqlite3c.tcl cc sqlite3.c -o sqlite3 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to `_WinMain@16' collect2: ld returned 1 exit status make: *** [sqlite3] Error 1 $ #c8c8c8 2858 build closed 2007 Dec anonymous 2008 Jan danielk1977 3 3 amalgamated sqlite3.c requires sqlite3ext.h Staring with SQLite 3.5.3, the "amalgamted" source file sqlite3.c requires sqlite3ext.h to compile. This is because sqlite3.c attempts to effectively include sqlite3ext.h instead of simply copying/pasting its contents: $ grep sqlite3ext.h sqlite3.c #define SQLITE_CORE 1 /* Disable the API redefinition in sqlite3ext.h */ /************** Include sqlite3ext.h in the middle of loadext.c **************/ /************** Begin file sqlite3ext.h **************************************/ ** @(#) $Id: sqlite3ext.h,v 1.17 2007/08/31 16:11:36 drh Exp $ /************** End of sqlite3ext.h ******************************************/ #include "sqlite3ext.h" /************** Include sqlite3ext.h in the middle of fts3_tokenizer.c *******/ /************** Begin file sqlite3ext.h **************************************/ ** @(#) $Id: sqlite3ext.h,v 1.17 2007/08/31 16:11:36 drh Exp $ /************** Include sqlite3.h in the middle of sqlite3ext.h **************/ /************** Continuing where we left off in sqlite3ext.h *****************/ /************** End of sqlite3ext.h ******************************************/ Compare to earlier versions such as SQLite 3.5.2: #define SQLITE_CORE 1 /* Disable the API redefinition in sqlite3ext.h */ /************** Include sqlite3ext.h in the middle of loadext.c **************/ /************** Begin file sqlite3ext.h **************************************/ ** @(#) $Id: sqlite3ext.h,v 1.17 2007/08/31 16:11:36 drh Exp $ /************** End of sqlite3ext.h ******************************************/ If you look at it in context you can see that sqlite3ext.h will never be #included since SQLITE_CORE is defined. #ifndef SQLITE_CORE #include "sqlite3ext.h" SQLITE_EXTENSION_INIT1 #endif ---- _2007-Dec-29 10:16:59 by anonymous:_ {linebreak} And yet SQLite 3.5.2 doesn't build here, maybe because SQLITE_CORE is not defined here. Where and how should SQLITE_CORE be defined? ---- _2007-Dec-29 10:24:58 by anonymous:_ {linebreak} We compile SQLite with SQLITE_OMIT_LOAD_EXTENSION defined. ---- _2007-Dec-30 13:10:01 by anonymous:_ {linebreak} OK, I now understand the problem much better. Below is a short explanation. My apologies for the initial bug report, it was a bit misleading and not detailed enough. You've added _fts3.c_ to the amalgamated source file of SQLite, starting with version 3.5.3. Now _"sqlite3ext.h"_ is needed by two of the amalgamated files: *: _loadext.c_: It includes _"sqlite3ext.h"_ and =SQLITE_CORE= must be defined first. *: _fts3.c_: It includes _"sqlite3ext.h"_ and I think =SQLITE_CORE= must be defined first since the FTS3 module is being built into the core of SQLite and not as an extension. There are actually many issues: 1: I think the amalgamated source file should never include _"sqlite3ext.h"_. Instead its should copy/paste its contents when needed. This is done for _loadext.c_ but not for _fts3.c_, resulting in the following error when building _sqlite3.c_ without _"sqlite3ext.h"_: {linebreak} =sqlite3.c:80297:26: error: sqlite3ext.h: No such file or directory= {linebreak} =sqlite3.c:80335: error: expected ',', ';', 'asm' or '__attribute__' before 'static'= {linebreak} =sqlite3.c:86299: error: expected ';', ',' or ')' before '*' token= {linebreak} I solved this by making sure =SQLITE_CORE= is defined when processing the contents of _fts3.c_, whether =SQLITE_OMIT_LOAD_EXTENSION= is defined or not, by moving: {linebreak} =#ifndef SQLITE_OMIT_LOAD_EXTENSION= {linebreak} after the block starting with: {linebreak} =#define SQLITE_CORE 1 /* Disable the API redefinition in sqlite3ext.h */= {linebreak} =/************** Include sqlite3ext.h in the middle of loadext.c **************/= 2: The FTS3 module in the amalgamated source file is built into the resulting library when =SQLITE_CORE= is not defined, whether =SQLITE_ENABLE_FTS3= is defined or not: {linebreak} =#if !defined(SQLITE_CORE) || defined(SQLITE_ENABLE_FTS3)= {linebreak} {linebreak} =#if defined(SQLITE_ENABLE_FTS3) && !defined(SQLITE_CORE)= {linebreak} =# define SQLITE_CORE 1= {linebreak} =#endif= {linebreak} =[...]= {linebreak} I'm not sure that's on purpose. Do you want the FTS3 module always built into the resulting SQLite library? If so, I think it would be more readable not to trigger this by defining =SQLITE_CORE=. Or at the very least it could be triggered by defining =SQLITE_ENABLE_FTS3= if =SQLITE_CORE= is defined in a single place - not all over the FTS3 source files. Is there any chance this ticket is opened again? Should I open a new ticket instead ? ---- _2007-Dec-30 17:17:07 by anonymous:_ {linebreak} SQLITE_CORE is defined previously in sqlite3.c. You can define it yourself on the commandline if you like. What compiler are you using? Will it #include a file even when it is not wanted, as in: #if 0 #include "foo.h" #endif or #ifdef SOME_UNDEFINED_MACRO #include "bar.h" #endif ---- _2007-Dec-30 17:53:42 by anonymous:_ {linebreak} I can recreate your problem. If I use http://sqlite.org/sqlite-amalgamation-3_5_4.zip, unzip it, delete sqlite3ext.h and grab shell.c from CVS:
$ gcc -I. -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c -o shell -lpthread sqlite3.c:81710:26: error: sqlite3ext.h: No such file or directory sqlite3.c:81748: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘static’ sqlite3.c:87815: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ tokenYou must use both -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_CORE on the compile line: gcc -I. -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_CORE shell.c sqlite3.c -o shell -lpthread That's a bug. The workaround is simple, though - always compile with -DSQLITE_CORE As you've found out, if you choose to build with FTS3 support you do not have to #define SQLITE_CORE on the compile line, as it defines it for you: gcc -I. -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_ENABLE_FTS3 shell.c sqlite3.c -o shell -lpthread ---- _2007-Dec-30 17:55:25 by anonymous:_ {linebreak} I'm using GCC, Visual Studio, Intel C++, HP ANSI C/aC++, SGI MIPSpro, Sun Studio, IBM XL C and other compilers. They will certainly not #include a file even when it is not wanted. How is your remark related to the use case exposed above? ---- _2007-Dec-30 18:08:50 by anonymous:_ {linebreak} Ignore the #include thing - it was just an idea. The sqlite bug is explained in detail in the 2007-Dec-30 17:53:42 comment. ---- _2007-Dec-30 18:09:36 by anonymous:_ {linebreak} Indeed, =SQLITE_CORE= is usually defined by the _loadext.c_ source code. Unfortunately this will not happen if =SQLITE_OMIT_LOAD_EXTENSION= is defined. The _fts3.c_ source code in the amalgamated source file needs to be compiled with =SQLITE_CORE= if we want it: *: not to include _"sqlite3ext.h"_, *: and not to build the FTS3 module unless =SQLITE_OMIT_LOAD_EXTENSION= is defined. So yes, the solution is to define =SQLITE_CORE= when building the amalgamated source file: *: either from the command line, in which case this requirement needs to be documented, *: or within the amalgamated source file itself, in which case {linebreak} =#define SQLITE_CORE 1= {linebreak} should be added before any reference to _sqlite3ext.h". ---- _2008-Jan-01 05:51:17 by danielk1977:_ {linebreak} Thanks. #cfe8bd 2846 build fixed 2007 Dec anonymous 2007 Dec 1 1 --disable-tcl does not work rm -rf tsrc mkdir -p tsrc cp ./src/alter.c ./src/analyze.c ./src/attach.c ./src/auth.c ./src/btmutex.c ./src/btree.c ./src/btree.h ./src/build.c ./src/callback.c ./src/complete.c ./src/date.c ./src/delete.c ./src/expr.c ./src/func.c ./src/hash.c ./src/hash.h ./src/insert.c ./src/journal.c ./src/legacy.c ./src/loadext.c ./src/main.c ./src/malloc.c ./src/mem1.c ./src/mem2.c ./src/mem3.c ./src/mem4.c ./src/mutex.c ./src/mutex_os2.c ./src/mutex_unix.c ./src/mutex_w32.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pager.h ./src/parse.y ./src/pragma.c ./src/prepare.c ./src/printf.c ./src/random.c ./src/select.c ./src/shell.c ./src/sqlite.h.in ./src/sqliteInt.h ./src/table.c ./src/tclsqlite.c ./src/tokenize.c ./src/trigger.c ./src/utf.c ./src/update.c ./src/util.c ./src/vacuum.c ./src/vdbe.c ./src/vdbe.h ./src/vdbeapi.c ./src/vdbeaux.c ./src/vdbeblob.c ./src/vdbefifo.c ./src/vdbemem.c ./src/vdbeInt.h ./src/vtab.c ./src/where.c ./ext/fts1/fts1.c ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.c ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_porter.c ./ext/fts1/fts1_tokenizer.h ./ext/fts1/fts1_tokenizer1.c sqlite3.h ./src/btree.h ./src/btreeInt.h ./src/hash.h ./src/sqliteLimit.h ./src/mutex.h opcodes.h ./src/os.h ./src/os_common.h ./src/sqlite3ext.h ./src/sqliteInt.h ./src/vdbe.h parse.h ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_tokenizer.h ./src/vdbeInt.h tsrc cp: warning: source file `./src/btree.h' specified more than once cp: warning: source file `./src/hash.h' specified more than once cp: warning: source file `./src/sqliteInt.h' specified more than once cp: warning: source file `./src/vdbe.h' specified more than once cp: warning: source file `./ext/fts1/fts1.h' specified more than once cp: warning: source file `./ext/fts1/fts1_hash.h' specified more than once cp: warning: source file `./ext/fts1/fts1_tokenizer.h' specified more than once cp: warning: source file `./src/vdbeInt.h' specified more than once rm tsrc/sqlite.h.in tsrc/parse.y cp parse.c opcodes.c keywordhash.h tsrc tclsh ./tool/mksqlite3c.tcl make: tclsh: Command not found make: *** [sqlite3.c] Error 127 _2007-Dec-17 00:45:26 by anonymous:_ {linebreak} Seems the same problem as #2845 #f2dcdc 2844 build active 2007 Dec anonymous 2007 Dec 4 1 lemon is being built without respecting LDFLAGS lemon is being built without respecting LDFLAGS. I'm attaching a patch which fixes this bug. In other words, why should we fix this? What problem is it causing? _2007-Dec-17 16:22:19 by drh:_ {linebreak} Why is this important? What LDFLAGS settings might a user want to carry through into lemon? ---- _2007-Dec-17 18:00:59 by anonymous:_ {linebreak} > Why is this important? It is considered to be be good practice to respect user's LDFLAGS. A user might want to have all executables and libraries built with identical LDFLAGS. > What LDFLAGS settings might a user want to carry through into lemon? A user might have LDFLAGS="-Wl,-O1,--hash-style=gnu,--sort-common" You can read http://lwn.net/Articles/192082/. Users can also use some other flags. > In other words, why should we fix this? What problem is it causing? It slightly increases the size of lemon executable and it slightly decreases performance. ---- _2007-Dec-17 18:04:31 by drh:_ {linebreak} lemon is used as an intermediate build tool in part of the SQLite build process. It is not a deliverable. If it runs a little slower or uses a little more memory, nobody cares. We only care if it gets the wrong answer. Is it ever possible that the lack of LDFLAGS support might result in lemon getting the wrong answer? ---- _2007-Dec-17 18:27:33 by anonymous:_ {linebreak} Can you comment on Lemon bug in #2835? It produces 2 different sqlite3.c files depending on your malloc implementation. ---- _2007-Dec-17 19:19:01 by anonymous:_ {linebreak} > lemon is used as an intermediate build tool in part of the > SQLite build process. It is not a deliverable. If it runs a > little slower or uses a little more memory, nobody cares. CFLAGS are respected when lemon is being built, so for consistency LDFLAGS also should be respected. (The comment above was not created by me.) #c8c8c8 2836 build closed 2007 Dec anonymous 2007 Dec 1 1 Undefined symbol 'OP_StackDepth' There is a error on current cvs version(12/12/07) with "Undefined symbol 'OP_StackDepth'" message. opcodes.h and opcodes.c havn't 'OP_StackDepth' definition currently. Sorry for my short English. _2007-Dec-13 07:41:07 by danielk1977:_ {linebreak} opcodes.c and opcodes.h are auto-generated files (generated based on vdbe.c). Likely your copies have not been regenerated since yesterdays modifications. Try running "make clean" before rebuilding. If that fails, manually remove opcodes.c and opcodes.h from your build directory. #cfe8bd 2826 build fixed 2007 Dec anonymous 2007 Dec 4 4 test_thread.c won't build if !SQLITE_THREADSAFE || !TCL_THREADS Trying a quick build of the test sources I discovered that test_thread.c won't build the null-test, since it requires tcl.h for a Tcl typedef for the function signature but only includes tcl.h if it thinks it's doing something useful. The following patch fixes the problem:
diff -cr unpack-orig/sqlite-3.5.3/src/test_thread.c sqlite-3.5.3/src/test_thread.c *** unpack-orig/sqlite-3.5.3/src/test_thread.c Mon Sep 10 11:53:02 2007 --- sqlite-3.5.3/src/test_thread.c Thu Dec 6 14:26:16 2007 *************** *** 18,27 **** */ #include "sqliteInt.h" #if SQLITE_THREADSAFE && defined(TCL_THREADS) - #include#f2dcdc 2813 build active 2007 Nov anonymous 2007 Nov 1 1 compile error on Windows CE environment: visual c++ 2005 window ce 6.0 customize sdk sqlite-amalgamation-3_5_3 I get error: Error 27 error C2040: 'localtime' : 'tm *(const time_t *)' differs in levels of indirection from 'int ()' d:\SubProjects\Sqlite\sqlite3.c 18574 but if I add code in line 7095: struct tm *__cdecl localtime(const time_t *t); then Success! #cfe8bd 2800 build fixed 2007 Nov anonymous 2007 Nov 5 5 -lpthread not needed for publish.sh for CLI binary -lpthread not needed by publish.sh for CLI binary since not threadsafe build. +CFLAGS="-Os -DSQLITE_ENABLE_FTS3=1 -DSQLITE_THREADSAFE=0" +echo '***** '"COMPILING sqlite3-$VERS.bin..." +gcc $CFLAGS -Itsrc sqlite3.c tsrc/shell.c -o sqlite3 -ldl -lpthread ldd ./sqlite3-3.5.3.bin linux-gate.so.1 => (0xb7f1d000) libdl.so.2 => /lib/libdl.so.2 (0xb7f05000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb7ef2000) libc.so.6 => /lib/i686/libc.so.6 (0xb7dc5000) /lib/ld-linux.so.2 (0xb7f1e000) Unrelated - why are the shared libs and binary chmod'ed to be not executable? chmod 644 sqlite3-$VERS.bin.gz chmod 644 tclsqlite3.so chmod 644 sqlite3.so The webserver used by www.sqlite.org treats any file with execute permission as a CGI program and tries to run it. So we have to remove the execution permission bit from files which are intended to be served intact. ---- _2007-Nov-27 19:00:03 by anonymous:_ {linebreak} Instead of gzipping the files directly, can you wrap the individual files in a tar.gz instead? This way they could retain the executable permission. UNIX novices may not know about chmod. #cfe8bd 2799 build fixed 2007 Nov anonymous 2007 Nov 3 3 'configure ' cannot locate VERSION file 'configure' diff: 18437c18437 < ALLOWRELEASE="-release `cat VERSION`" --- > ALLOWRELEASE="-release `cat $srcdir/VERSION`" #c8c8c8 2798 build closed 2007 Nov anonymous 2007 Nov 3 4 Wrong nm used when cross-compiling When cross-compiling, the build platforms nm is used, instead of the one for the target platform. I included a patch for Makefile.in and configure.ac to start using the detected nm instead of the hardcoded 'nm'. _2007-Nov-27 14:53:06 by drh:_ {linebreak} The configure script is a mess and I am disinclined to make it a bigger mess by trying to fix cross-compilation. A better approch to cross-compiling is to use the amalgamation. Build the amalgamation using: make sqlite3.c Then compile sqlite3.c for your target system using whatever cross-compiler you want. #cfe8bd 2788 build fixed 2007 Nov anonymous 2007 Nov drh 3 3 FormatMessageA not defined for Windows Mobile Compiling SQLite 3.5.2 with embedded Visual C++ 4 produces the following link error: os_win.obj : error LNK2019: unresolved external symbol FormatMessageA referenced in function winDlError The only occurence of FormatMessageA is in os_win.c. Windows Mobile doesn't support ASCII, only wide characters. Since LoadLibrary isn't supported in winDlOpen on Windows Mobile, I suggest the following patch for winDlError: #if OS_WINCE if (nBuf > 0) zBufOut[0] = '\0'; #else FormatMessageA( FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), 0, zBufOut, nBuf-1, 0 ); #endif Already fixed by check-in [4541]. #f2dcdc 2787 build active 2007 Nov anonymous 2007 Nov 4 5 sqlite3.pc is not remade the subject says it all, there is no make rule to rebuild the sqlite3.pc from the .in file. it is only possible by hand (./config.status sqlite3.pc) _2007-Nov-22 12:17:50 by drh:_ {linebreak} I don't know what the sqlite3.pc file does. I certainly do not use it for any of my builds on Linux, Mac OSX, or windows. Why should I leave it in the source tree? Isn't the best solution to this problem to simply delete the file? ---- _2007-Nov-22 17:14:27 by anonymous:_ {linebreak} It is indirectly used by pkgconfig. Here's some info on pkgconfig: http://pkg-config.freedesktop.org/wiki/ ---- _2007-Nov-23 15:22:32 by drh:_ {linebreak} Could somebody who understands what the sqlite3.pc file is used for suggest a makefile rule for rebuilding it? #cfe8bd 2780 build fixed 2007 Nov anonymous 2007 Nov 3 3 sqliteint.h: test to disable _XOPEN_SOURCE uses wrong macro for OSX sqliteint.h tests for __MACOS__ for whether to define _XOPEN_SOURCE on OSX. But this is not the correct macro (I think it's an old OS9 macro). __APPLE__would be a better choice. #f2dcdc 2763 build active 2007 Nov anonymous 2007 Nov 4 4 AIX build failure due to explicit _XOPEN_SOURCE definition Our AIX machine has started having problems building the new sqlite 3.5.2 source. I'm no AIX expert, but I did some digging and I think it's due to sqliteInt.h defining _XOPEN_SOURCE without also defining _ALL_SOURCE. AIX system header files usually define this themselves (in /usr/include/ standards.h) but only if _XOPEN_SOURCE was previously undefined. Has anyone else come across this bug? I'm willing to believe it's our build system if not; we can work around it by setting _ALL_SOURCE on the command-line, but I thought it might be useful to raise a bug anyway. See also tickets #2673, #2681, and #2741. I do not have access to an AIX machine and so have no ability to debug this problem. If you have suggested patches we will consider them. Otherwise, there is not much we can do about this ticket. #c8c8c8 2751 build closed 2007 Oct anonymous 2007 Nov 2 3 Regression - Solaris/sparc throws BUS ERROR on count()/sum()/etc. A regression has crept into sqlite 3.5 (both 3.5.0 and 3.5.1) running on Solaris/sparc when built with GCC (both 3.4.2 and 4.2.2 tested) which leads to a BUS ERROR when simple count()/sum() queries are run. A workaround is to build with Solaris CC. Example session: # ./sqlite3 SQLite version 3.5.1 Enter ".help" for instructions sqlite> create table foo(a); sqlite> insert into foo values(1); sqlite> select count(a) from foo; Bus error (core dumped) _2007-Oct-31 18:19:12 by danielk1977:_ {linebreak} Can you check that applying this clears the problem? Thanks. diff -u -r1.110 vdbeapi.c --- src/vdbeapi.c 17 Oct 2007 01:44:21 -0000 1.110 +++ src/vdbeapi.c 31 Oct 2007 18:15:44 -0000 @@ -446,7 +446,7 @@ pMem->flags = MEM_Agg; pMem->xDel = sqlite3_free; pMem->u.pDef = p->pFunc; - if( nByte<=NBFS ){ + if( nByte<=NBFS && 0 ){ pMem->z = pMem->zShort; memset(pMem->z, 0, nByte); }else{ ---- _2007-Nov-02 09:06:57 by anonymous:_ {linebreak} I can confirm that your patch prevents the crash. Thank you. ---- _2007-Nov-05 05:51:35 by anonymous:_ {linebreak} Do you attribute this error to be a compiler bug or a problem in SQLite? ---- _2007-Nov-05 06:20:42 by danielk1977:_ {linebreak} Sorry, I missed your post on November 2. I think it's an alignment problem. Without the patch, sqlite3_aggregate_context() is returning a pointer to a pre-allocated buffer. The problem is (I suspect) that the start of this buffer is not aligned to an 8-byte boundary as required by your architecture. So I figure an SQLite bug, not a compiler problem. Will fix shortly. ---- _2007-Nov-05 14:41:25 by anonymous:_ {linebreak} Perhaps zShort should be moved after a double in the struct for alignment?#include #include --- 18,27 ---- */ #include "sqliteInt.h" + #include #if SQLITE_THREADSAFE && defined(TCL_THREADS) #include #include
diff -u -3 -p -r1.130 vdbeInt.h --- src/vdbeInt.h 28 Aug 2007 23:28:08 -0000 1.130 +++ src/vdbeInt.h 5 Nov 2007 14:39:04 -0000 @@ -123,6 +123,7 @@ struct Mem { FuncDef *pDef; /* Used only when flags==MEM_Agg */ } u; double r; /* Real value */ + char zShort[NBFS]; /* Space for short strings */ sqlite3 *db; /* The associated database connection */ char *z; /* String or BLOB value */ int n; /* Number of characters in string value, including '\0' */ @@ -130,7 +131,6 @@ struct Mem { u8 type; /* One of SQLITE_NULL, SQLITE_TEXT, SQLITE_INTEGER, etc */ u8 enc; /* SQLITE_UTF8, SQLITE_UTF16BE, SQLITE_UTF16LE */ void (*xDel)(void *); /* If not null, call this function to delete Mem.z */ - char zShort[NBFS]; /* Space for short strings */ }; typedef struct Mem Mem;#f2dcdc 2736 build active 2007 Oct anonymous 2007 Oct 2 2 build problems on freebsd on freebsd: --disable-threads does not work. it is accepted as a valid option but no defs are added to the makefile -lgcc needs to be included in SHLIB_LD_LIBS pkgIndex.tcl is not built when -DSQLITE_THREADSAFE=0 is added manually, this causes the install target to fail. _2007-Oct-17 21:16:23 by anonymous:_ {linebreak} I forgot to mention this is with the TEA version #f2dcdc 2727 build active 2007 Oct anonymous 2007 Oct 4 4 building with -malign-double causes strange behavior sqlite 3.5.1 amalgamation has problems when enabling a wide set of compiler features on gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) on linux/i686 /w glibc-2.5 strange behavior occurs. typical strangeness is that SQLITE_FULL is returned from sqlite3_prepare_v2() (called immediately after a statement was created with sqlite3_mprintf). This happens even though there is a reasonable amount of disk space free (6G). the compile line looks like:{linebreak} cc -g -pg -O1 -march=i686 -msse2 -malign-double -m128bit-long-double -momit-leaf-frame-pointer -minline-all-stringops -D_XOPEN_SOURCE=520 '-DVERSION="0.10r276M"' -Isqlite/ -DSQLITE_OMIT_LOAD_EXTENSION -DTHREADSAFE=0 -DSQLITE_OMIT_EXPLAIN -DSQLITE_ENABLE_COLUMN_METADATA -c -o sqlite/sqlite3.o sqlite/sqlite3.c and valgrind reports:{linebreak} ==15323== Use of uninitialised value of size 4{linebreak} ==15323== at 0x80585B7: insertElement (sqlite3.c:13072){linebreak} ==15323== by 0x807366E: sqlite3HashInsert (sqlite3.c:13290){linebreak} ==15323== by 0x809FE72: unixOpen (sqlite3.c:15403){linebreak} ==15323== by 0x80579A7: sqlite3OsOpen (sqlite3.c:8210){linebreak} ==15323== by 0x806B12F: sqlite3BtreeFactory (sqlite3.c:21317){linebreak} ==15323== by 0x80767BA: openDatabase (sqlite3.c:71237){linebreak} ==15323== by 0x8076BD1: sqlite3_open (sqlite3.c:71337){linebreak} ==15323== by 0x804BEAE: db_init (dbmgr.c:81){linebreak} ==15323== by 0x804CE64: main (main.c:59){linebreak} my dbmgr.c:81:db_init() is: res=sqlite3_open(filename, &system_db); and system_db=NULL and filename="zomg.sqlite" (string literal). so the parameters seem normal. if I turn off -malign-double everything works fine. (this "bug" also seems to be on 3.4.1 amalgamation) _2007-Oct-14 04:35:16 by anonymous:_ {linebreak} This is a compiler issue. -malign-double creates problems for most programs. What are you trying to accomplish? #c8c8c8 2718 build closed 2007 Oct anonymous 2007 Oct 2 1 WinCE compile error On function winOpen
#if OS_WINCE if( (flags & (SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB)) == (SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB) && !winceCreateLock(zFilename, pFile) ){ CloseHandle(h); free(zConverted); return SQLITE_CANTOPEN; } if( dwFlagsAndAttributes & FILE_FLAG_DELETE_ON_CLOSE ){ pFile->zDeleteOnClose = zConverted; }else #endifThat zFilename of the winceCreateLock call doesn't exist. I guess it should be zName instead Duplicate of #2700 #cfe8bd 2713 build fixed 2007 Oct anonymous 2007 Oct 1 5 build fails for 3.5.1 on win32/cygwin - duplicate opcode labels Problem: build fails on compiling vdbe.c => src/vdbe.c: In function `sqlite3VdbeExec': src/vdbe.c:1136: error: duplicate case value src/vdbe.c:921: error: previously used here src/vdbe.c:1655: error: duplicate case value src/vdbe.c:900: error: previously used here ... Seems like my generated opcodes.h has lots of duplicates: #define OP_Multiply 80 /* same as TK_STAR */ #define OP_Pull 80 #define OP_Dup 71 #define OP_Lt 71 /* same as TK_LT */ I'm running on XP with a c:\cygwin library available. NB. i'm not a regular SQLLite user and was just trying the library out of curiosity so if no one else reports this then don't sweat it... it may be down to my environment screwing up the build process. _2007-Oct-09 17:15:24 by drh:_ {linebreak} Why don't you try compiling the {link: /cvstrac/wiki?p=TheAmalgamation amalgamation} instead? ---- _2007-Oct-09 18:06:22 by anonymous:_ {linebreak} Original poster - just run "make clean" and try again. ---- (OP) OK. tracked it down to the initialisation of the tk array in mkopcodeh.awk which is getting strings like "22 " (not sure if this is a space or a CR). the following patch fixes it for me: --- mkopcodeh.awk-orig 2007-03-29 19:39:30.000000000 +0100 +++ mkopcodeh.awk 2007-10-12 15:14:46.980260800 +0100 @@ -41,7 +41,9 @@ # Remember the TK_ values from the parse.h file /^#define TK_/ { - tk[$2] = $3 + num = $3 + num += 0 # convert "22 " -> 22 + tk[$2] = num } # Scan for "case OP_aaaa:" lines in the vdbe.c file ie. ensure that the keys are numeric. With this patch, the build completes ok. Thanks. ---- _2007-Oct-12 20:08:41 by anonymous:_ {linebreak} It's not an AWK bug in Cygwin. The only way to convert strings to numbers in AWK is to add zero. Cygwin uses the same version of GNU gawk as Linux. It's the exact same code. ---- _2007-Oct-12 20:43:55 by drh:_ {linebreak} Seems like if it were exactly the same code it would work exactly the same. But clearly it does not. I don't know what is going on. Probably some strange DOS \r line ending problems. Presumably the change has fixed the problem. #c8c8c8 2692 build closed 2007 Oct anonymous 2007 Oct 1 1 COmpilation of Sqlite amalgamation v3.4.2. failed Version 3.4.2 (amalgamation) could not be compiled under MS DevStudio 6 the compilation errors are: sqlite3.c(6187) : error C2133: 'sqlite3UpperToLower' : unknown size sqlite3.c(9310) : error C2133: 'sqlite3OpcodeNames' : unknown size sqlite3.c(47159) : error C2133: 'sqlite3IsIdChar' : unknown size _2007-Oct-04 18:19:44 by drh:_ {linebreak} Duplicate of #2574. #c8c8c8 2689 build closed 2007 Oct anonymous 2007 Oct 3 4 make test fails in 3.5.1 - unresolved externals in testfixture tar zxvf sqlite...... cd sqlite-3.5.1 mkdir bld cd bld ../configure make make test ./libtool --mode=link gcc -g -O2 -I. -I../src -DNDEBUG -I/System/Library/Frameworks/Tcl.framework/Versions/8.4/Headers -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 \ -DSQLITE_NO_SYNC=1 -DTEMP_STORE=1 \ -o testfixture ../src/attach.c ../src/btree.c ../src/build.c ../src/date.c ../src/expr.c ../src/func.c ../src/insert.c ../src/malloc.c ../src/os.c ../src/os_os2.c ../src/os_unix.c ../src/os_win.c ../src/pager.c ../src/pragma.c ../src/prepare.c ../src/printf.c ../src/select.c ../src/test1.c ../src/test2.c ../src/test3.c ../src/test4.c ../src/test5.c ../src/test6.c ../src/test7.c ../src/test8.c ../src/test9.c ../src/test_autoext.c ../src/test_async.c ../src/test_btree.c ../src/test_config.c ../src/test_hexio.c ../src/test_malloc.c ../src/test_md5.c ../src/test_schema.c ../src/test_server.c ../src/test_tclvar.c ../src/tokenize.c ../src/utf.c ../src/util.c ../src/vdbe.c ../src/vdbeapi.c ../src/vdbeaux.c ../src/vdbemem.c ../src/where.c parse.c ../src/tclsqlite.c \ libsqlite3.la -framework Tcl -lpthread -framework CoreFoundation gcc -g -O2 -I. -I../src -DNDEBUG -I/System/Library/Frameworks/Tcl.framework/Versions/8.4/Headers -DSQLITE_THREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTCLSH=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DSQLITE_NO_SYNC=1 -DTEMP_STORE=1 -o .libs/testfixture ../src/attach.c ../src/btree.c ../src/build.c ../src/date.c ../src/expr.c ../src/func.c ../src/insert.c ../src/malloc.c ../src/os.c ../src/os_os2.c ../src/os_unix.c ../src/os_win.c ../src/pager.c ../src/pragma.c ../src/prepare.c ../src/printf.c ../src/select.c ../src/test1.c ../src/test2.c ../src/test3.c ../src/test4.c ../src/test5.c ../src/test6.c ../src/test7.c ../src/test8.c ../src/test9.c ../src/test_autoext.c ../src/test_async.c ../src/test_btree.c ../src/test_config.c ../src/test_hexio.c ../src/test_malloc.c ../src/test_md5.c ../src/test_schema.c ../src/test_server.c ../src/test_tclvar.c ../src/tokenize.c ../src/utf.c ../src/util.c ../src/vdbe.c ../src/vdbeapi.c ../src/vdbeaux.c ../src/vdbemem.c ../src/where.c parse.c ../src/tclsqlite.c -framework Tcl -framework CoreFoundation ./.libs/libsqlite3.dylib -lpthread /usr/bin/ld: Undefined symbols: _Sqlitetest7_Init _SqlitetestOnefile_Init _SqlitetestThread_Init collect2: ld returned 1 exit status make: *** [testfixture] Error 1 _2007-Oct-04 11:21:47 by anonymous:_ {linebreak} This is mac os x ---- _2007-Oct-04 15:40:13 by anonymous:_ {linebreak} Same unresolved externals for testfixture on Linux. Fix below. Do a "make distclean" and re-run configure/make test.
Index: Makefile.in =================================================================== RCS file: /sqlite/sqlite/Makefile.in,v retrieving revision 1.183 diff -u -3 -p -r1.183 Makefile.in --- Makefile.in 3 Sep 2007 22:15:45 -0000 1.183 +++ Makefile.in 4 Oct 2007 15:37:57 -0000 @@ -212,6 +212,8 @@ SRC += \ # Source code to the test files. # TESTSRC = \ + $(TOP)/src/test_onefile.c \ + $(TOP)/src/test_thread.c \ $(TOP)/src/attach.c \ $(TOP)/src/btree.c \ $(TOP)/src/build.c \ Index: src/test7.c =================================================================== RCS file: /sqlite/sqlite/src/test7.c,v retrieving revision 1.9 diff -u -3 -p -r1.9 test7.c --- src/test7.c 12 Sep 2007 17:01:45 -0000 1.9 +++ src/test7.c 4 Oct 2007 15:37:57 -0000 @@ -21,8 +21,8 @@ ** This test only works on UNIX with a SQLITE_THREADSAFE build that includes ** the SQLITE_SERVER option. */ -#if defined(SQLITE_SERVER) && !defined(SQLITE_OMIT_SHARED_CACHE) -#if defined(OS_UNIX) && OS_UNIX && SQLITE_THREADSAFE +#if defined(SQLITE_SERVER) && !defined(SQLITE_OMIT_SHARED_CACHE) && \ + defined(OS_UNIX) && OS_UNIX && SQLITE_THREADSAFE #include---- _2007-Oct-04 15:43:15 by anonymous:_ {linebreak} Output of make test after patch: 0 errors out of 31801 tests All memory allocations freed - no leaks Maximum memory usage: 14160983 bytes ---- _2007-Oct-04 19:09:05 by anonymous:_ {linebreak} I am the original reporter - that fix worked for me, thanks. My results (OS X) 0 errors out of 31207 tests All memory allocations freed - no leaks Maximum memory usage: 14161431 bytes #c8c8c8 2688 build closed 2007 Oct anonymous 2007 Oct 3 1 SQLITE_OMIT_AUTHORIZATION build failure Version 3.5.1 does not compile when specifying -DSQLITE_OMIT_AUTHORIZATION. The problem lies on line 6872 (of the amalgamation): =# define sqlite3AuthRead(a,b,c)= should be: =# define sqlite3AuthRead(a,b,c,d)= thanks. #cfe8bd 2673 build fixed 2007 Sep anonymous 2007 Oct 4 4 3.5.0 amalgamation on OS X, "#define _XOPEN_SOURCE 500" fails build In the first amalgamation release for 3.5.0, the following #define causes a build problem on Mac OS X 10.4. #define _XOPEN_SOURCE 500 /* Needed to enable pthread recursive mutexes */ This is not needed on OS X and, instead, causes _POSIX_C_SOURCE to be #defined around line 280 in#include @@ -720,5 +720,4 @@ int Sqlitetest7_Init(Tcl_Interp *interp) } #else int Sqlitetest7_Init(Tcl_Interp *interp){ return TCL_OK; } -#endif /* OS_UNIX */ #endif
#if OS_WINCE if( (flags & (SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB)) == (SQLITE_OPEN_READWRITE|SQLITE_OPEN_MAIN_DB) && !winceCreateLock(zFileName, &f) ){ CloseHandle(h); free(zConverted); return SQLITE_CANTOPEN; } if( dwFlagsAndAttributes & FILE_FLAG_DELETE_ON_CLOSE ){ pFile->zDeleteOnClose = zConverted; }else #endifThe line 18511 should be: && !winceCreateLock(zName, pFile) Also it's have mistake in typing FILE_FLAG_DELETE_ON_CLOSE (with last underlines - FILE_FLAG_DELETEONCLOSE in line 18517). Please change the sources to be compiled for WindowsCE. BR. Yuri Noyanov #f2dcdc 2645 build active 2007 Sep anonymous 2007 Sep 5 4 Conflict between tclConfig.sh and tclinstaller.tcl I'm using a non-standard location for Tcl: --with-tcl=/home/scott/lib The build process finds and uses the tclConfig.sh file from /home/scott/lib just fine, but tclinstaller.tcl is called without an explicit path and uses the system's tclsh instead of the one in /home/scott/bin and thus tries to install that portion of code into the system's area. While I can change my path to resolve this, I think it makes more sense for tclinstaller.tcl to use the path information that's embedded in tclConfig.sh to be consistent. /s. #cfe8bd 2633 build fixed 2007 Sep anonymous 2007 Sep 1 1 building with gcc3.3.4 - undefined reference to `sqlite3KeywordCode' I'm using gcc 3.3.4 with glibc 2.3.2 trying to cross compile for arm. My configure command line: ../sqlite-3.4.2/configure --disable-readline --disable-tcl --host=arm-linux --prefix=/usr/local/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/ During the build I have to compile lemon and mkkeywordhash for my native system and restart the build. Otherwise the build goes smoothly until I get here: ... ranlib .libs/libsqlite3.a creating libsqlite3.la (cd .libs && rm -f libsqlite3.la && ln -s ../libsqlite3.la libsqlite3.la) ./libtool --mode=link gcc -I/usr/local/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/include -I. -I../sqlite-3.4.2/src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -L/usr/local/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/lib -DHAVE_READLINE=0 \ -o sqlite3 ../sqlite-3.4.2/src/shell.c libsqlite3.la \ gcc -I/usr/local/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/include -I. -I../sqlite-3.4.2/src -DNDEBUG -DTHREADSAFE=0 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DHAVE_READLINE=0 -o .libs/sqlite3 ../sqlite-3.4.2/src/shell.c -L/usr/local/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/lib ./.libs/libsqlite3.so -Wl,--rpath -Wl,/usr/local/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux//lib ./.libs/libsqlite3.so: undefined reference to `sqlite3KeywordCode' ./.libs/libsqlite3.so: undefined reference to `keywordCode' collect2: ld returned 1 exit status make: *** [sqlite3] Error 1 I'm trying to build the shared libraries for use on an arm system. I'd just build the sqlite3.c amalgamation into my apps, but I had a grocery list of build errors in gcc 4.1.2 on my native system and I didn't think my gcc3.3.4 cross-compiler would fair much better. So I'd like to at least get the shared libs working. Any help would be appreciated. I figured out that the build does not warn you if keywordhash.h is not created. Perhaps it should or the build will fail. So after compiling the mkkeywordhash tool for the native machine: gcc -g -o mkkeywordhash ../sqlite-3.4.2/tool/mkkeywordhash.c I then had run: ./mkkeywordhash >keywordhash.h ... manually before restarting the build. Build completes without errors now, but build tools/code generators are inherently non-cross-compiler friendly when they are part of the main build process and have to be compiled into machine executable form before being run. Any possibility of moving these to an interpreter-based language that doesn't require compiling? #c8c8c8 2625 build closed 2007 Sep anonymous 2007 Sep 2 2 http://www.sqlite.org/cvstrac/wiki?p=HowToCompileWithVsNet has problem when i compile 3.4.2 with visual studio 2003 in windows, i do as http://www.sqlite.org/cvstrac/wiki?p=HowToCompileWithVsNet told me to. but step 8 "Add all the .c and .h files that you unzipped, except for: tclsqlite.c and shell.c.Note: You may add tclsqlite.c and shell.c, but then you have to define the preprocessor-symbol NO_TCL:" won't work. i suggest to modify it to be "Add all the .c and .h files that you unzipped, except for: tclsqlite.c shell.c and icu.c. Note: You may add tclsqlite.c and shell.c, but then you have to define the preprocessor-symbol NO_TCL, you may add icu.c, but then you have to define the preprocessor-symbol SQLITE_CORE". why not supply a .sln file? this will save many people's time. thank you. _2007-Sep-06 07:04:34 by danielk1977:_ {linebreak} What you suggest sounds like an improvement. I'd add the text in myself, but I don't have visual studio, so I can't test it. But the wiki pages are all user editable, so feel free to modify it yourself by clicking the "Edit" link found at the top right-hand side of the page. If you have a *.sln file that you can attach to the page, even better. #c8c8c8 2605 build closed 2007 Aug anonymous 2007 Aug 1 3 Amalgamated version 3.4.2 doesn't compile (VC++6) In a project that already used versions 3.3.x through 3.3.17 (successfully) in "amalgamated" source, I substituted sqlite3.c and sqlite3.h from version 3.4.2, but I yield three compilation errors: ----------------------------------------------------------------- Compiling... {linebreak} sqlite3.c {linebreak} c:\lavoro\nonclassificato\resanddev\hcsprog\sqlite\sqlite3.c(6187) : error C2133: 'sqlite3UpperToLower' : unknown size {linebreak} c:\lavoro\nonclassificato\resanddev\hcsprog\sqlite\sqlite3.c(9310) : error C2133: 'sqlite3OpcodeNames' : unknown size {linebreak} c:\lavoro\nonclassificato\resanddev\hcsprog\sqlite\sqlite3.c(47159) : error C2133: 'sqlite3IsIdChar' : unknown size {linebreak} Error executing cl.exe. {linebreak} ----------------------------------------------------------------- They all are related to array declaration missing size in brackets. Duplicate of ticket #2574. Already fixed. #f2dcdc 2587 build active 2007 Aug anonymous 2007 Aug 3 4 Build problem when using the SQLITE_OMIT_FLOATING_POINT define. I apologize in advance if the values I chose above are not appropriate. If I define SQLITE_OMIT_FLOATING_POINT=1 and try to build a Windows DLL, I get two errors in loadext.c, line 116 and 192. "error C4028: formal para meter 3 different from declaration" I believe you want to change the include order at the top of loadext.c from: #include "sqlite3ext.h" #include "sqliteInt.h" to: #include "sqliteInt.h" #include "sqlite3ext.h" Reversing the order of include fixes my build. Yes, I know there is no real reason to disable floating point for the Windows DLL. I'm actually porting SqLite for use in an NT kernel mode driver and avoiding floating point operations will save a lot of time if I don't really need them and I don't. So I made sure this was a problem with a supported platform like the Windows DLL and griped about that instead of my insanity. ;-) You can email questons to mspiegel@vipmail.com. If you want to discuss this over the phone, shoot me an email and I'll send you phone numbers. #cfe8bd 2583 build fixed 2007 Aug anonymous 2007 Aug 2 2 3.4.2 fails to build on Solaris due to conflict for B_FALSE and B_TRUE While attempting to build SQLite 3.4.2 on Solaris 10/x86 with gcc 3.4.3, I get this error: gcc -D_REENTRANT -g -O2 -o lemon ./tool/lemon.c ./tool/lemon.c:111: error: conflicting types for 'B_FALSE' /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.3/include/sys/types.h:193: error: previous definition of 'B_FALSE' was here ./tool/lemon.c:111: error: conflicting types for 'B_TRUE' /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.3/include/sys/types.h:193: error: previous definition of 'B_TRUE' was here Here is the conflicting line in /sqlite/tool/lemon.c 111 typedef enum {B_FALSE=0, B_TRUE} Boolean; And the conflict in the gcc version of =sys/types.h=: 190 #if defined(__XOPEN_OR_POSIX) 191 typedef enum { _B_FALSE, _B_TRUE } boolean_t; 192 #else 193 typedef enum { B_FALSE, B_TRUE } boolean_t; 194 #endif /* defined(__XOPEN_OR_POSIX) */ Oddly enough, 3.4.1 built successfully despite having the same code in lemon.c. Possibly some header files have changed and are causing __XOPEN_OR_POSIX no longer to be defined. Workaround: rename B_FALSE to BOOL_FALSE and B_TRUE to BOOL_TRUE throughout lemon.c. #cfe8bd 2574 build fixed 2007 Aug anonymous 2007 Aug anonymous 3 3 amalgamation 3.4.2 compile errors The new amalgamation 3.4.2 fails with the following compile errors using Visual C++ (2003 and 2005): sqlite3.c(6187) : error C2133: 'sqlite3UpperToLower' : unknown size sqlite3.c(9310) : error C2133: 'sqlite3OpcodeNames' : unknown size sqlite3.c(47159) : error C2133: 'sqlite3IsIdChar' : unknown size Cause: The 'extern' keyword was replaced by 'SQLITE_PRIVATE' I suspect this should have been the new macro 'SQLITE_EXTERN' Changing from SQLITE_PRIVATE to SQLITE_EXTERN results in a successfull build _2007-Aug-15 10:35:23 by drh:_ {linebreak} The problem is that there is a declaration of the constant: SQLITE_PRIVATE const unsigned char sqlite3UpperToLower[]; Then later the constant is defined with its content: SQLITE_PRIVATE const unsigned char sqlite3UpperToLower[] = {...}; How does VC++ expect you to declare a static constant with file scope before it is defined? GCC is quite happy with the construct above. ---- _2007-Aug-15 12:56:30 by anonymous:_ {linebreak} VC++ is only happy when you declare it as: SQLITE_PRIVATE const unsigned char sqlite3UpperToLower[256]; It seems it has to know the size upfront. I've also tried various compiler switches, but no postive results. ---- _2007-Aug-15 13:29:05 by anonymous:_ {linebreak} C0x and C++0x seem to allow the construct of forward declaring an unknown sized array of static (file scope) types. I wonder if gcc in --pedantic mode might also complain about it. This compilation set of settings is what perl uses to help guarantee cross-platform portability: gcc -g -O -pedantic -Wall -W -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wno-long-long ---- _2007-Aug-15 13:29:41 by anonymous:_ {linebreak} Does VC++ allow the same forward declaration without const? SQLITE_PRIVATE unsigned char sqlite3UpperToLower[]; If not, putting the size in advance for the array forward declaration is acceptable. ---- _2007-Aug-15 13:36:57 by anonymous:_ {linebreak} SQLITE_PRIVATE unsigned char sqlite3UpperToLower[]; This produces the same error and also another one: error C2133: 'sqlite3UpperToLower' : unknown size error C2373: 'sqlite3UpperToLower' : redefinition; different type modifiers The second error was to be expected ---- _2007-Aug-15 13:42:36 by anonymous:_ {linebreak} A function could be created to simply return the pointer to the array in question. Seemingly inefficient, but any modern optimizing compiler in the last 5 years would inline this function call away if in the same translation unit, as in the amalgamation. ---- _2007-Aug-15 13:54:05 by anonymous:_ {linebreak} Just change the forward declaration to a pointer: SQLITE_PRIVATE const unsigned char *sqlite3UpperToLower; as well as the implementation: SQLITE_PRIVATE const unsigned char *sqlite3UpperToLower = { ... }; ---- _2007-Aug-15 14:08:11 by anonymous:_ {linebreak} Does VC++ like this? static char* arr; static char* arr; static char arr_impl[] = { 'f', 'o', 'o' }; static char *arr = arr_impl; ---- _2007-Aug-15 15:17:45 by anonymous:_ {linebreak} No, it does not. It gives redefinition warnings on the initializer. I think part of the problem is that 'static TYPE var;' is default initialized when it is seen, and SPACE IS ALLOCATED FOR IT in any compilation unit that sees it. It is not given external scope. What I think I see is that every part of the individual .c files were scanned for file-scope definitions, which were then placed into an internals.h file for inclusion across all things that needed it. What I think you'll see if you look at the .o files for each .c file compiled separately, is a definition for each of the static variables that you were trying to predeclare. I think they'll need extern scope if you want to gain access to them in separate compilation units. And I think it might be better to declare and use the opcodes list, the UpperToLower table, and the character map table as pointers rather than arrays. Or bite the bullet of using extern instead of static. If you want to avoid overrunning the length of the tables you could provide an accessor function when printing the vdbe opcodes which could do range checking. Similarly, you could use something that is C-compiler safe for doing compile-time assertions that the length of the character map and lower-case tables are exactly 256 entries long when initialized. static bool must_be_256_long[sizeof(table)==256]; ---- _2007-Aug-15 15:28:56 by anonymous:_ {linebreak} The compile assert is not portable. static int must_be_256_long[0]; gcc does not complain about this unless the -pedantic flag is used. ---- _2007-Aug-15 15:33:51 by anonymous:_ {linebreak} All the external variables in question should be moved to a seperate vars.h and vars.c file. The amalgamation would have this vars.c file added before all other sqlite3 .h/.c files, and the vars.h file need not be added to the amalgamation at all. vars.h would only be used for non-amalgamation builds. ---- _2007-Aug-15 15:34:14 by anonymous:_ {linebreak} Since it's explicitly defined later, why not just mark the forward declaration as "extern"? This involves removing the SQLITE_PRIVATE in front. VS2005 let it compile for me no problems. ---- _2007-Aug-15 18:05:49 by anonymous:_ {linebreak} gcc will not allow an extern forward declaration followed by a static declaration. For background of why things were done the way they are see Ticket #2554 "Many symbols not marked private/static or SQLITE_API in amalgamation" ---- _2007-Aug-16 13:57:34 by anonymous:_ {linebreak} It seems to me that there are only the three symbols in concern: *: the vdbe opcode-to-string table, which is used in one place and auto-generated into another. *Perhaps* the place that it is used within could #include the auto-generated file, and exclude the auto generated file from the remainder of the compilation. (by naming it with .h, if necessary.) *Alternatively*, it could be encapsulated in an accessor sub-function instead of directly referred to by its array-based name. *: the character map for converting ebcdic to lower-cased ascii, or the similar translation when converting ascii to lower-cased ascii. It's used by one function when converting from a TOKEN to a token ID. It could also be just IN the file marked as SQLITE_PRIVATE and not forward declared at all. *: the upper to lower converter is used in a few places :) . No easy/quick solution for that that doesn't involve a possible decrease in performance based on non-inlined function calls in non-amalgamation compiled libraries. #f2dcdc 2567 build active 2007 Aug anonymous 2007 Aug 3 2 Build fails to install I compile under MinGW with Msys. A build error occurs during 'make install'. After checking the makefile. The 'install' target depends on 'sqlite3', when it should be 'sqlite3$(TEXE)'. The workaround is, after configure, edit makefile for target install, and replace 'sqlite3' with 'sqlite3${TEXE}' where needed. I did not have this problem with 3.3.17. I assume this could be fixed just by fixing the configure to produce correct makefile. _2007-Aug-12 04:41:12 by anonymous:_ {linebreak} Do you have a patch? #f2dcdc 2566 build active 2007 Aug anonymous 2007 Aug 2 1 fts2 broken after vacuum Hi there, I'm testing your database and I'm having problems with fts2: --------- sqlite> select * from distB where distB match "MARIANO"; Assertion failed: *pData!='\0', file fts2amal.c, line 16790 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --------- Steps: 1) Create a new .db 2) Import data in new distA table 3) Import data in new distB table 4) Create a new distC virtual table (dts2) 5) insert into distC (rowid, f1, f2, f3) select rowid, f1, f2, f3 from DistB Everything working like a charm until here!!! The fts2 works very well, but after 6) vacuum; the fts seems broken... doing a select throws the error I paste at the post of the topic If you want the .db file I can send it to you (607MB) Thanks.- #c8c8c8 2557 build closed 2007 Aug anonymous 2007 Aug 3 3 make test errors on Rhel4 x86_64 Hello there, While building sqlite 3.4.1 rpms for Rhel4 on i386 and x86_64, I came across some inconsistent behaviour with "make test". On Rhel4.5 i386, "make test" works fine. However, on Rhel4.5 x86_64, "make test" has two errors which terminate the rpm build process. rpmbuild -bb --with tcl sqlite.spec 2>&1 | tee build.log{linebreak} .{linebreak} .{linebreak} printf-7.5... Ok{linebreak} printf-8.1...{linebreak} Error: integer value too large to represent{linebreak} printf-8.2...{linebreak} Error: integer value too large to represent{linebreak} printf-8.3... Ok{linebreak} .{linebreak} .{linebreak} Thread-specific data deallocated properly{linebreak} 2 errors out of 29903 tests{linebreak} Failures on these tests: printf-8.1 printf-8.2{linebreak} make: *** [test] Error 1{linebreak} error: Bad exit status from /var/tmp/rpm-tmp.97578 (%check){linebreak} My current workaround is to apply a patch which is only applied on x86_64 hardware. Again, thanks for your time and great software. _2007-Aug-07 17:17:39 by drh:_ {linebreak} Neither test is particularly important and both failures problem result from bugs in either TCL or somewhere else in RH, not in the SQLite core. If you want me to look into this, please consider publishing your patch. I have no way to reproduce the problem otherwise. #c8c8c8 2549 build closed 2007 Aug anonymous 2007 Aug 1 3 3.4.1 fails to upgrade from 3.3.1.7 on freeBSD I use DesktopBSD (freebsd), and I was running the regular software upgrade using the Package Manager. This is the result: ./.libs/libsqlite3.so: undefined reference to `sqlite3Fts2InitHashTable' gmake: *** [sqlite3] Error 1 *** Error code 2 Stop in /usr/ports/databases/sqlite3. *** Error code 1 Stop in /usr/ports/databases/sqlite3. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.64421.1 env DIALOG=/usr/local/bin/kdialog-ports-wrapper UPGRADE_TOOL=portupgrade UPGRADE_PORT=sqlite3-3.3.17 UPGRADE_PORT_VER=3.3.17 make ** Fix the problem and try again. Regards, Arthur This is a bug for the FreeBSD ports maintainers. #c8c8c8 2504 build closed 2007 Jul anonymous 2007 Jul 1 1 sqlite 3.4.0 fails to build FreeBSD 6.2 64-bit system Attached is the configure and make output. As this is a FreeBSD 6.2 AMD 64-bit box, several "warning: cast from pointer to integer of different size" in func.c, table.c, and vdbemem.c concern me as potential bugs. Added to the fact the the undefined reference to __isnanl. The warnings also appear in 3.3.17 version of SQLite, which I hadn't noticed before, but the there was no undefined reference preventing the build. _2007-Jul-13 17:13:47 by anonymous:_ {linebreak} submitter: anthony howe, achowe@snert.com ---- _2007-Jul-13 17:34:33 by drh:_ {linebreak} Already fixed by check-in [4103]. #c8c8c8 2501 build closed 2007 Jul anonymous 2007 Jul 2 3 limits.h confilct with visual studio limits.h When I include sqlite3.h in my code, and provide the sqlite headers folder to complier include path, limits.h is picked up from sqlite headers even when it must be picked from vc/include, so I get errors compiling other files that we compiling fine. Current workaround is I provide the parent folder of sqlite headers as include path for compiler and instead of #include "sqlite3.h", I do a #include "sqlite-3.4.0/sqlite3.h" _2007-Jul-12 20:39:41 by drh:_ {linebreak} See tickets #2428 and #2495. #cacae5 2499 build defer 2007 Jul anonymous 2007 Aug drh 1 1 undefined reference to `_WinMain@16' when attempting to build I get the error: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to `_WinMain@16' _2007-Jul-11 18:16:28 by anonymous:_ ls Makefile.in config.sub main.mk sqlite.pc.in Makefile.linux-gcc configure mkdll.sh sqlite3.1 README configure.ac mkopcodec.awk sqlite3.pc.in VERSION contrib mkopcodeh.awk src aclocal.m4 doc mkso.sh tclinstaller.tcl addopcodes.awk ext notes test art install-sh publish.sh tool config.guess ltmain.sh spec.template www ./configure && make install checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by gcc... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... file_magic ^x86 archive import|^x86 DLL checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 8192 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for correct ltmain.sh version... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk Version set to 3.4 Release set to 3.4.0 Version number set to 3004000 checking whether to support threadsafe operation... no checking whether to allow connections to be shared across threads... no checking whether threads can override each others locks... no checking whether to support shared library linked as release mode or not... no checking whether to use an in-ram database for temporary tables... no checking if executables have the .exe suffix... unknown checking host system type... (cached) i686-pc-cygwin checking for Tcl configuration... found /usr/lib/tclConfig.sh checking for existence of /usr/lib/tclConfig.sh... loading checking for library containing tgetent... -ltermcap checking for readline in -lreadline... no checking readline.h usability... no checking readline.h presence... no checking for readline.h... no checking for /usr/include/readline.h... no checking for /usr/include/readline/readline.h... no checking for /usr/local/include/readline.h... no checking for /usr/local/include/readline/readline.h... no checking for /usr/local/readline/include/readline.h... no checking for /usr/local/readline/include/readline/readline.h... no checking for /usr/contrib/include/readline.h... no checking for /usr/contrib/include/readline/readline.h... no checking for /mingw/include/readline.h... no checking for /mingw/include/readline/readline.h... no checking for library containing fdatasync... none required checking for usleep... yes checking for fdatasync... yes configure: creating ./config.status config.status: creating Makefile config.status: creating sqlite3.pc gcc -g -O2 -o lemon.exe ./tool/lemon.c cp ./tool/lempar.c . cp ./src/parse.y . ./lemon.exe parse.y mv parse.h parse.h.temp awk -f ./addopcodes.awk parse.h.temp >parse.h cat parse.h ./src/vdbe.c | gawk -f ./mkopcodeh.awk >opcodes.h sort -n -b -k 3 opcodes.h | gawk -f ./mkopcodec.awk >opcodes.c gcc -g -O2 -o mkkeywordhash.exe ./tool/mkkeywordhash.c ./mkkeywordhash.exe >keywordhash.h sed -e s/--VERS--/3.4.0/ ./src/sqlite.h.in | \ sed -e s/--VERSION-NUMBER--/3004000/ >sqlite3.h rm -rf tsrc mkdir -p tsrc cp ./src/alter.c ./src/analyze.c ./src/attach.c ./src/auth.c ./src/btree.c ./src/btree.h ./src/build.c ./src/callback.c ./src/complete.c ./src/date.c ./src/delete.c ./src/expr.c ./src/func.c ./src/hash.c ./src/hash.h ./src/insert.c ./src/legacy.c ./src/loadext.c ./src/main.c ./src/malloc.c ./src/os.c ./src/os_unix.c ./src/os_win.c ./src/os_os2.c ./src/pager.c ./src/pager.h ./src/parse.y ./src/pragma.c ./src/prepare.c ./src/printf.c ./src/random.c ./src/select.c ./src/shell.c ./src/sqlite.h.in ./src/sqliteInt.h ./src/table.c ./src/tclsqlite.c ./src/tokenize.c ./src/trigger.c ./src/utf.c ./src/update.c ./src/util.c ./src/vacuum.c ./src/vdbe.c ./src/vdbe.h ./src/vdbeapi.c ./src/vdbeaux.c ./src/vdbeblob.c ./src/vdbefifo.c ./src/vdbemem.c ./src/vdbeInt.h ./src/vtab.c ./src/where.c ./ext/fts1/fts1.c ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.c ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_porter.c ./ext/fts1/fts1_tokenizer.h ./ext/fts1/fts1_tokenizer1.c sqlite3.h ./src/btree.h ./src/btreeInt.h ./src/hash.h ./src/limits.h opcodes.h ./src/os.h ./src/os_common.h ./src/sqlite3ext.h ./src/sqliteInt.h ./src/vdbe.h parse.h ./ext/fts1/fts1.h ./ext/fts1/fts1_hash.h ./ext/fts1/fts1_tokenizer.h ./src/vdbeInt.h tsrc cp: warning: source file `./src/btree.h' specified more than once cp: warning: source file `./src/hash.h' specified more than once cp: warning: source file `./src/sqliteInt.h' specified more than once cp: warning: source file `./src/vdbe.h' specified more than once cp: warning: source file `./ext/fts1/fts1.h' specified more than once cp: warning: source file `./ext/fts1/fts1_hash.h' specified more than once cp: warning: source file `./ext/fts1/fts1_tokenizer.h' specified more than once cp: warning: source file `./src/vdbeInt.h' specified more than once rm tsrc/sqlite.h.in tsrc/parse.y cp parse.c opcodes.c keywordhash.h tsrc tclsh ./tool/mksqlite3c.tcl cc sqlite3.c -o sqlite3 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to `_WinMain@16' collect2: ld returned 1 exit status make: *** [sqlite3] Error 1 ---- _2007-Jul-11 18:17:17 by anonymous:_ {linebreak} when initially filing this bug, i was told to not paste large screen dumps. i was also promised that i would be able to add an attachment later. however, that option was not given, so I have attached a screen transcript. ---- _2007-Jul-11 18:18:33 by anonymous:_ {linebreak} my email is metaperl at gmail.com ---- _2007-Jul-11 18:38:53 by drh:_ {linebreak} The [Attach] link in the upper-left is what you use to add attachments. The sqlite3.c source file is a library, not a program. If you want to compile a command-line shell, add the "shell.c" source file: cc -o sqlite3 sqlite3.c shell.c ---- _2007-Jul-23 20:35:06 by anonymous:_ {linebreak} I believe this bug report should be reopened because this error comes when you try to configure and compile USING THE DEFAULTS. When you try to do a standard configure and make, it should either try to compile shell.c as is needed or not compile sqlite.c. It shouldn't put in a command that fails the compile by default. Sorry to bother you about this, but I don't see how this isn't a bug or at least a glitch. It's a problem in the configuration and makefile system. ---- _2007-Aug-15 03:26:05 by anonymous:_ {linebreak} Compile and link passed by following patch (at least for me). diff -ru sqlite-3.4.2/Makefile.in sqlite-3.4.2-new/Makefile.in --- sqlite-3.4.2/Makefile.in 2007-08-15 10:37:18.921875000 +0900 +++ sqlite-3.4.2-new/Makefile.in 2007-08-15 10:36:08.750000000 +0900 @@ -681,7 +681,7 @@ mkdir -p doc mv $(DOC) doc -install: sqlite3 libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install} +install: sqlite3$(TEXE) libsqlite3.la sqlite3.h ${HAVE_TCL:1=tcl_install} $(INSTALL) -d $(DESTDIR)$(libdir) $(LTINSTALL) libsqlite3.la $(DESTDIR)$(libdir) $(INSTALL) -d $(DESTDIR)$(exec_prefix)/bin ---- _2007-Aug-22 12:33:17 by anonymous:_ {linebreak} Why is this bug closes and marked "not a bug"? sqlite fails on make install on Cygwin (as in untar/configure/make/make install), which is *clearly* a bug. The "fix" posted above does not work, make install fails instantly with tclsh ../sqlite-3.4.2-n/tclinstaller.tcl 3.4 can't read "env(DESTDIR)": no such variable while executing "set LIBDIR $env(DESTDIR)$env(TCLLIBDIR)" (file "../sqlite-3.4.2-n/tclinstaller.tcl" line 11) make: *** [tcl_install] Error 1 ---- _2007-Aug-22 12:53:45 by drh:_ {linebreak} I misread the problem. Cygwin is not a supported platform. So in that sense, this is *not* clearly a bug in SQLite. This is an imcompatibility with Cygwin. We will take the problem under advisement, but since Cygwin is not officially support and because we have many much more serious problems to work on, progress on this is likely to be slow. You can expedite a fix by posting a patch. #c8c8c8 2493 build closed 2007 Jul anonymous 2007 Jul 2 3 Fails to build under GCC-4.1.3 on FreeBSD-6.2 OS: FreeBSD-6.2 When using the build-in gcc 3.4.6 [FreeBSD] 20060305, sqlite3, version 3.3.17 builds fine. However, when using gcc 4.1.3 20070618, sqlite3 version 3.3.17 fails to build. A copy of the failed build attempt is attached. _2007-Jul-09 13:23:38 by anonymous:_ ===> Applying FreeBSD patches for sqlite3-3.3.17 Your SQLite sources have apparently been modified for FreeBSD. This is a question for the BSD port system maintainers or simply google "unable to infer tagged configuration" where you will find many workarounds for your operating system. libtool: link: unable to infer tagged configuration libtool: link: specify a tag with `--tag' gmake: *** [libsqlite3.la] Error 1 *** Error code 2 Stop in /usr/ports/databases/sqlite3. ---- _2007-Jul-21 19:58:11 by anonymous:_ {linebreak} This is a libtool bug that happens when the C compiler you're using is not named 'gcc'. As a workaround in your case: CC=/usr/local/bin/gcc41 ./configure make Above command assumes bash shell. Use appropriate construct for other shells. #c8c8c8 2489 build closed 2007 Jul anonymous 2007 Jul 1 1 Latest cvs 3.4.0 make test fails related to TCL Here's how I'm building. I've tried --disable-tcl and --enable-tcl with no joy. I'm using latest Fedora 7 with tcl-8.4.13 installed. mkdir -p /build/work/sqlite-3.4.0.1 cd /build/work/sqlite-3.4.0.1 unset CDPATH export CFLAGS='-pipe -O3 -g' make distclean cvs -d :pserver:anonymous@www.sqlite.org:/sqlite -r update . ./configure --prefix=/usr/local/pkgs/sqlite-3.4.0.1 --disable-tcl make groupadd vuser || /bin/true useradd -M -g vuser -d /vhost/davidfavor.com/users/david -s /bin/zsh david || /bin/true useradd -M -g vuser -d /vhost/livefeast.com/users/yemiah -s /bin/zsh yemiah || /bin/true chown david:vuser -R . su -c "make test" david /build/work/sqlite-3.4.0.1/./src/tclsqlite.c:2416: undefined reference to `Tcl_CreateObjCommand' /build/work/sqlite-3.4.0.1/./src/tclsqlite.c:2417: undefined reference to `Tcl_PkgProvide' /build/work/sqlite-3.4.0.1/./src/tclsqlite.c:2418: undefined reference to `Tcl_CreateObjCommand' ... hundreds of errors deleted ... "make test" requires Tcl to function. Post the result of "grep -i tcl config.log" after you run ./configure with no arguments. The key to it working is finding tclConfig.sh
configure:19220: checking for Tcl configuration configure:19302: result: found /usr/lib/tclConfig.sh configure:19305: checking for existence of /usr/lib/tclConfig.sh ac_cv_c_tclconfig=/usr/lib HAVE_TCL='1' TCL_BIN_DIR='/usr/lib' TCL_INCLUDE_SPEC='-I/usr/include/tcl8.4.13' TCL_LIBS='-ldl -lpthread -lieee -lm' TCL_LIB_FILE='libtcl8.4.so' TCL_LIB_FLAG='-ltcl8.4' TCL_LIB_SPEC='-L/usr/lib -ltcl8.4' TCL_SRC_DIR='/usr/include/tcl8.4.13' TCL_STUB_LIB_FILE='libtclstub8.4.a' TCL_STUB_LIB_FLAG='-ltclstub8.4' TCL_STUB_LIB_SPEC='-L/usr/lib -ltclstub8.4' TCL_VERSION='8.4'---- _2007-Jul-07 03:49:21 by anonymous:_ {linebreak} Ah I see now. I'm using a 64 bit machine so tcl lives in the 64 bit directory hierarchy. Here's how I got most of the tests to run: export CFLAGS='-pipe -O3 -g -DSQLITE_DISABLE_DIRSYNC=1 -Wall' make distclean cvs -d :pserver:anonymous@www.sqlite.org:/sqlite -r update . ./configure --prefix=/usr/local/pkgs/sqlite-3.4.0.1 --enable-tcl --with-tcl=/usr/lib64 This ticket can close. I'll do some further testing and open another ticket about the single thread test that fails. ---- _2007-Jul-07 11:43:05 by drh:_ {linebreak} Please note that this is an open ticketing system. Anybody can close a ticket. You do not need to ask me or Dan to do it. #f2dcdc 2469 build active 2007 Jun anonymous 2007 Jul 1 1 test fails on Solaris I have a problem running the test suite on Solaris 9. Build was done using gcc 4.2.0. The build completes without error but many tests fail. I've created my own minimal test that exhibits the problem:
set testdir [file dirname $argv0] source $testdir/tester.tcl db close file delete -force test.db test.db-journal sqlite db test.db do_test tdb-1 { execsql { PRAGMA auto_vacuum = 1; BEGIN; CREATE TABLE t1(a, b); } execsql { COMMIT; } } {} integrity_check tdb-2 finish_testWhen running this test I get the following output:
tdb-1... Ok tdb-2... Expected: [ok] Got: [{*** in database main *** List of tree roots: 2nd reference to page 1 Page 3 is never used}] Thread-specific data deallocated properly 1 errors out of 3 tests Failures on these tests: tdb-2This error happens on lots of, but not all, tests. I'm happy to do whatever is necessary to help debug this. Thanks, Tim. _2007-Jun-27 10:44:14 by anonymous:_ {linebreak} Further to this, it appears to be related to gcc 4.2.0. It works fine with gcc 3.4.6. ---- _2007-Jun-28 09:54:35 by anonymous:_ {linebreak} Further more, it doesn't appear to be specific to Solaris. The same problem occurs on Linux with gcc 4.2.0. So I guess the subject of this ticket should be changed to "build/test problems with gcc 4.2.0". This is probably a significant problem - the build completes find but the resultant code is broken. People may not notice this until it's too late. ---- _2007-Jun-28 12:24:05 by drh:_ {linebreak} I installed gcc 4.2.0 on my SuSE linux i686 desktop and built test harnesses under three different configurations: gcc420 -g -O0 -Wall -fstrict-aliasing gcc420 -g -O3 -Wall gcc420 -g -O3 -fstrict-aliasing -fomit-frame-pointer The first two configurations used separate source files. The third configuration was built using the amalgamation. I ran the "quick" test under all configurations. All tests ran to completion with no errors. ---- _2007-Jun-28 13:22:20 by anonymous:_ {linebreak} Two ideas: 1. Compile with gcc 4.2.0 using -O0 instead of -O2 and see what happens. Disable any other optimizations you may have. 2. Run truss with full read/write buffer display on the gcc 3.4.6 compiled testfixture running your simple test case and compare its output to the gcc 4.2.0 compiled test case. ---- _2007-Jul-01 19:00:40 by anonymous:_ {linebreak} I've done tests with optimisation, and this appears to tickle the problem. With no optimisation, -O, -O0, -O1 and -03 it works. With -O2 and -Os it's broken. I was compiling with -O2 when I submitted the initial report. Tim. ---- _2007-Jul-01 19:54:54 by drh:_ {linebreak} I can reproduce the problem now on Linux when compiling as follows: gcc420 -g -O2 -Wall ---- _2007-Jul-01 21:50:42 by drh:_ {linebreak} This appears to be a bug in GCC 4.3.0. A work-around is to compile with the -fno-tree-vrp option. GCC appears to miscompile a single loop within the logic that implements the integrity_check PRAGMA. The code that gets miscompiled is in the file vdbe.c (lines numbers added): 4308 for(j=0; j
RCS file: /sqlite/sqlite/src/vdbe.c,v retrieving revision 1.636 diff -u -3 -p -r1.636 vdbe.c --- src/vdbe.c 1 Jul 2007 21:18:40 -0000 1.636 +++ src/vdbe.c 21 Jul 2007 19:10:13 -0000 @@ -4306,7 +4306,8 @@ case OP_IntegrityCk: { pnErr = &p->aMem[j]; assert( (pnErr->flags & MEM_Int)!=0 ); for(j=0; ju.i; } aRoot[j] = 0; popStack(&pTos, nRoot);