Re: [sqlite] Proposed sqlite3_initialize() interface
On Oct 30, 2007, at 7:18 AM, [EMAIL PROTECTED] wrote: As currently implemented, SQLite3 requires no initialization. You just start calling SQLite3 interfaces and they work. We can pull off this trick on Unix because pthread mutexes can be initialized statically at compile-time. static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; On win32, we have to initialize mutexes at run-time, but this can be done within a contrived mutex that we build off of a static integer using InterlockedIncrement(). And mutex initialization apparently never fails on win32, so we do not have to worry with reporting errors that occur during mutex initialization. But there are other operating systems using SQLite that do not work this way. They need a way to initialize mutexes (and possibly other objects such as malloc) prior to running any SQLite interface. And the initialization needs to be able to fail and return an error code. To accomodate this need, we are considering an incompatible API change to SQLite. We are thinking of requiring that an application invoke: int sqlite3_initialize(...); prior to using any other SQLite interface. (The parameters to sqlite3_initialize() are not yet designed.) It will be an error to use any other SQLite interface without first invoking sqlite3_initialize() exactly one. It is also an error to invoke sqlite3_initialize() more than once. Existing applications that use SQLite would have to be modified to invoke sqlite3_initialize(). Presumably this would happen very early in main(), before any threads were created. No other code changes would be required. I assume (hope) you mean threads that call into sqlite3. We have a situation where 'sqlite3_initialize' would be called far away from any 'main' - sqlite3 is a runtime loaded extension for the Chicken Scheme system. There isn't any guarantee when the extension is loaded, and therefore when the initialization is done. I doubt any problems but just a heads up that sqlite3 is used in a manner differing from the above scenario by languages such as Scheme, Io, Lua, OCaml, etc. This is still just an idea. If you think that adding a new required sqlite3_initialize() interface would cause serious hardship for your use of SQLite, please speak up now. -- D. Richard Hipp <[EMAIL PROTECTED]> -- --- To unsubscribe, send email to [EMAIL PROTECTED] -- --- Best Wishes, Kon - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] -O3 compile w/ SQLite 3.3.14 (current cvs) Results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 3, 2007, at 9:14 AM, [EMAIL PROTECTED] wrote: Kon Lovett <[EMAIL PROTECTED]> wrote: Hi, I recall a request for -O3 optimization results w/ the current source. MacOS X 10.4.9 GCC 4.0.1 (Apple Extensions) PowerPC G4 (32-bit) Tcl 8.4 Configure: --enable-threadsafe --enable-cross-thread-connections -- enable-threads-override-locks --enable-tempstore Can you try again without the "--enable-tempstore" and see what happens? 0 errors out of 26431 tests (So much for that option for me) -- D. Richard Hipp <[EMAIL PROTECTED]> -- --- To unsubscribe, send email to [EMAIL PROTECTED] -- --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iEYEARECAAYFAkYSk3wACgkQJJNoeGe+5O7cAACghCc3DrQKjqAj/VEjbSqNyY2R z1wAn0TBU8aEh5YSJXEYCGV1yR4FGrwW =ZCc2 -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] -O3 compile w/ SQLite 3.3.14 (current cvs) Results
Hi,
I recall a request for -O3 optimization results w/ the current source.
MacOS X 10.4.9
GCC 4.0.1 (Apple Extensions)
PowerPC G4 (32-bit)
Tcl 8.4
Configure: --enable-threadsafe --enable-cross-thread-connections --
enable-threads-override-locks --enable-tempstore
Optimization Flags: -O3 -mcpu=7450 -mtune=7450
TCC += -DSQLITE_ENABLE_LOCKING_STYLE=1
conflict-6.2...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.3...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.7...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.8...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.9...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.10...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
conflict-6.11...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.12...
Expected: [0 {6 7 3 9} 1 1]
Got: [0 {6 7 3 9} 1 0]
conflict-6.13...
Expected: [0 {7 6 9} 1 1]
Got: [0 {7 6 9} 1 0]
exclusive-1.0...
Expected: [normal normal exclusive]
Got: [normal normal normal]
exclusive-1.2...
Expected: [exclusive exclusive exclusive]
Got: [exclusive exclusive normal]
exclusive-1.4...
Expected: [normal normal exclusive]
Got: [normal normal normal]
exclusive-1.6...
Expected: [normal normal exclusive]
Got: [normal normal normal]
exclusive-1.8...
Expected: [normal exclusive exclusive]
Got: [normal normal exclusive]
exclusive-1.12...
Expected: [normal exclusive normal normal]
Got: [normal normal normal normal]
exclusive-1.13...
Expected: [normal exclusive normal normal normal]
Got: [normal normal normal normal normal]
pragma-9.10...
Expected: [1 {no such table: temp_store_directory_test}]
Got: [0 2]
Best Wishes,
Kon
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
[sqlite] MacOS X build failure
Hi, The following occurs building the CVS head w/ gcc 4.0.1 on MacOS 10.4.6: ./libtool --mode=compile gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. - I../sqlite/src -DNDEBUG -DSQLITE_ALLOW_XTHREAD_CONNECT=1 -I/usr/local/ include -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=1 - DSQLITE_OMIT_CURSOR -c ../sqlite/src/loadext.c gcc -g -O2 -DOS_UNIX=1 -DHAVE_USLEEP=1 -I. -I../sqlite/src -DNDEBUG - DSQLITE_ALLOW_XTHREAD_CONNECT=1 -I/usr/local/include -DTHREADSAFE=1 - DSQLITE_THREAD_OVERRIDE_LOCK=1 -DSQLITE_OMIT_CURSOR -c ../sqlite/src/ loadext.c -fno-common -DPIC -o .libs/loadext.o ../sqlite/src/loadext.c: In function 'sqlite3CloseExtensions': ../sqlite/src/loadext.c:285: error: 'SQLITE_LIBRARY_TYPE' undeclared (first use in this function) ../sqlite/src/loadext.c:285: error: (Each undeclared identifier is reported only once ../sqlite/src/loadext.c:285: error: for each function it appears in.) ../sqlite/src/loadext.c:285: error: parse error before ')' token Probably 'HAVE_DLOPEN' not defined but don't know why. Thank you in advance, Kon
Re: [sqlite] Advice on compiling 3.5.5 for Mac OS X?
On May 21, 2006, at 2:09 PM, Thomas Chust wrote: On Sun, 21 May 2006, Jerry Krinock wrote: I would like to compile SQLite 3.3.5 for Mac OS 10.3 and Mac OS 10.4. [...] Are there any tricks that I should know about before attempting this? [...] Hello, I had no trouble whatsoever to build the standard UNIX tarball of SQLite 3.3.5 on MacOS X 10.4.6 by just unpacking it, running ./ configure and running make. I must add, though, that I built against a libreadline that I installed myself instead of the MacOS X system supplied one -- I don't know whether this makes any difference for SQLite, but I recollect that the system supplied libreadline in MacOS X is quite broken and many other things I installed by hand failed to build against it correctly. I second this. I am not even sure /usr/lib/libreadline.dylib is readline. It is a symbolic link to libedit.dylib for me. So I use my own build of readline as well. Uh, for 10.3 you will have a little work (unless compiling on a 10.3 installation). You will need to specify the compiler version since the runtime system is different. An XCode project for SQlite 3 would be nice but I don't have one. Best Wishes, Kon cu, Thomas
