There are several build options in the configure/make of sqlite3 that
are obsolete, and others that are missing.
ENCODING is obsolete since it is specified in the open calls now.
There are still several references to it, though, in the make and
autoconf files, and these should all be removed.
Yeah. There are some odd failures on MacOSX. Which processor are you
using (G3, G4, G5)?
I'm using an iBook with a G3 processor @ 700 MHz.
On a G4 dual 450MHz I got the following errors:
37 errors out of 21955 tests
Failures on these tests: printf-1.11.1 printf-1.11.2 printf-1.11.3
John LeSueur wrote:
> The reason [the short_column_names] pragma is important to me is for
> compatibility with existing codebases. I have a couple large applications
> that run on postgres, that I am porting to a desktop application that will
> use sqlite as the backend. I would rather not add as
There seems to be a bug with pragma short_column_names that if it is
set, column names are blank. Attached is a patch to
fix this. To be honest, I'm not very familiar with sqlite's codebase, so
the P3_STATIC is kind of a guess, but it compiled
and ran just fine. The reason this pragma is
Stephen C. Gilardi wrote:
func-12.7... Ok
func-13.1... Ok
func-13.2... Ok
func-13.3... Ok
func-13.4...make: *** [test] Bus error
Fixed an uninitialized variable. The failure above should
no longer happen.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
Nuno Lucas wrote:
"make test" fails with a segmentation fault, shown below:
-
..
func-12.7... Ok
func-13.1... Ok
func-13.2... Ok
func-13.3... Ok
func-13.4...make: *** [test] Segmentation fault
This should be fixed in the lastest version in CVS. Please
Daniel K ([EMAIL PROTECTED]) wrote:
> Can you try the following experiment and post the
> results:
> CREATE TABLE tbl(a INTEGER PRIMARY KEY, b INTEGER);
> INSERT INTO tbl VALUES( -1, 1.12589990684e+15 );
> SELECT * FROM tbl;
> and see what happens. If you get the right value
> back (-1,
"make test" fails with a segmentation fault, shown below:
-
..
func-12.7... Ok
func-13.1... Ok
func-13.2... Ok
func-13.3... Ok
func-13.4...make: *** [test] Segmentation fault
[EMAIL PROTECTED] $ uname -a
Linux tux 2.4.25_pre7-gss-r5 #5 SMP Tue Jun 8
=== On 2004-06-19, D. Richard Hipp wrote ===
>The missing routines were added to Tcl/Tk in version 8.3.
>Version 8.4.6 is current. Strange that Gentoo would be using
>the very latest version of GCC but still have an archaic
>version of TCL.
>
>I think it is not unreasonable to require Tcl 8.4 in
ok, I am using tcl-8.3.4 so that explains it.
Regards,
~Nuno Lucas
=== On 2004-06-19, Daniel K wrote ===
>To fix this you need a TCL upgrade. Any 8.4.* will
>work.
>Dan.
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Le samedi 19 Juin 2004 13:48, Daniel K a écrit :
> To fix this you need a TCL upgrade. Any 8.4.* will
Thanks. Maybe this could fix my make doc problem too.
I use tcl-8.3.5 for now.
I'll try an upgrade.
--
JCR
aka DJ Anubis
LAB Project Initiator & coordinator
At 13:15 19/06/2004, you wrote:
The previous version included the SQLite code in the DLL. This version
loads the SQLite DLL at runtime and calls into it - that way there is no
built-in dependency on the SQLite version.
Very cool :-)
Fred.
The previous version included the SQLite code in the DLL.
This version loads the SQLite DLL at runtime and calls into it - that way
there is no built-in dependency on the SQLite version.
Steve
-Original Message-
From: Frederic Faure [mailto:[EMAIL PROTECTED]
Sent: 19 June 2004 11:52
To:
"Steve O'Hara" >> If you can think of improvements, let me know.
I noticed that the output DLL shrank yet again to 45KB :-) What did you do
to make it so small?
Fred.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
On Visual Studio .NET 2003, there is a warning that can be easily eliminated
on "os.c", line 836:
os.c, line 835 ---
}else{
zDir = sqlite_temp_directory;
}
---
The compiler warns about assigning a const pointer to a non-const pointer.
Casting it,
hello,
compiling SQLite 3.0.0 in an cygwin environment I am getting compiler
warnings:
../sqlite/src/util.c:1175: warning: integer constant is too large for
"long" typ
../sqlite/src/vdbe.c:3022: warning: integer constant is too large for "long" typ
../sqlite/src/vdbe.c:3029: warning: integer
Le samedi 19 Juin 2004 09:28, Hans-Juergen Taenzer a écrit :
> But for example in the interface file sqlite(3).h there is not made
> use of this typedef (or INT64_TYPE defined in sqliteInt.h):
>
> long long int sqlite3_value_int64(sqlite3_value*);
try to patch as:
INT64_TYPE
DJ Anubis ([EMAIL PROTECTED]) wrote:
> Le vendredi 18 Juin 2004 22:20, Hans-Juergen Taenzer a écrit :
>> I don't think there would be problems with the new version 3.0 if
>> there wasn't the problem with the 'long long' datatype. Just
>> using a suitable typdef for this datatype would
Le samedi 19 Juin 2004 08:34, Daniel K a écrit :
> You mean the sqlite3_exec() enters an infinite loop
> and never returns? If you get the chance, can you post
> an example of SQL that causes this. Thanks.
Sorry for the inconvenience. Problem solved running through gdb.
This was a bug on mine. I
> However, trigger.c might need some optimizations, as
> we can end up with endless triggerings when using
> somewhat complex queries.
You mean the sqlite3_exec() enters an infinite loop
and never returns? If you get the chance, can you post
an example of SQL that causes this. Thanks.
Dan.
Le samedi 19 Juin 2004 05:32, Steve Palmer a écrit :
> I see versions of this for Linux and Windows, but not for Mac OSX.
> Are the sources going to be made available so that we can build for
> our platform?
Should work for MacOS X. See os_mac.h comment
** This header file defines OS-specific
Built v3 on the following systems:
Linux Fedora Core 1 on AMD Athlon XP 2800+
Linux Mandrake 10 on a dual PIII 700
Linux RHE 3 on a dual Itanium 2 box.
the make doc should be revised, as common.tcl is no more in package.
Checked all of this using a script generating a database with 100
tables,
22 matches
Mail list logo
