Re: [sqlite] SQLite version 3.6.23
Are you sure this is right? Now the header sqlite3.h is a duplicate of the source sqlite3.c and sqlite3.c is double the size it should be. On Mar 9, 2010, at 4:04 PM, D. Richard Hipp wrote: > > On Mar 9, 2010, at 4:40 PM, Terence Martin wrote: > >> On Tue, 9 Mar 2010 16:00:27 -0500 >> "D. Richard Hipp" <d...@hwaci.com> wrote: >> >>> SQLite version 3.6.23 is now available from the SQLite website: >>> http://www.sqlite.org/ >>> >>> >>> As always, please let me know if you find any problems in the new >>> release. >>> >>> D. Richard Hipp >>> d...@hwaci.com >> >> I think there may be a problem with the currentl 3.6.23 amalgamation >> download. First I noticed that it compiled the library fine but blew >> up >> in shell.c (2418) with an error regarding SQLITE_CONFIG_LOG not being >> defined. >> >> On closer examination it appears that the sqlite3.[ch] files are from >> 3.6.22 (they diff out to be identical). >> >> I double checked that the file I downloaded says it's 3.6.23. > > Yes - there was a boo boo in the build. Please download a fresh copy > and try again. > > >> ___ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > D. Richard Hipp > d...@hwaci.com > > > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." <Ha, ha> "And it might give 'em all stomach ulcers." - Tarzan, on war ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3 for Mac OSX 10.5
I have a SQLite3 framework. Universal binaries for Tiger thru Snow Leopard (though I'm not maintaining for Tiger any more). http://www.kyngchaos.com/software:frameworks On Nov 10, 2009, at 3:07 PM, Peter Haworth wrote: > sqlite3 is rejecting a SELECT statement that includes the group_concat > function saying it's an unknown function, yet the same SELECT > statement works fine in the Firefox SQLite Manager extension. > > The version of sqlite3 on my Mac is 3.4.0 but it looks like the latest > version is 3.6.x. Could that be the cause of the problem and if so, > where can I get that version (already compiled) for the Mac? > > Thanks, > > Pete Haworth - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Mac OS Snow Leopard 32bit vs 64bit
Odd, works fine here. ... ah, make sure you use the --disable- dependency-tracking option. The default dependency tracking does not work with multiple architectures. It's just a compilation process and not using it has no effect on the generated code. On Oct 14, 2009, at 7:42 PM, Melton Low wrote: > I got a compile error when the 64bit flag was include. Worked fine > if I > just use the 32bit flag. > Thanks for your help. > > Mel > > On Wed, Oct 14, 2009 at 6:01 PM, William Kyngesburye > <wokl...@kyngchaos.com>wrote: > >> Add this to your configure command (applies to most all configures): >> >> CFLAGS="-arch i386 -arch x86_64" >> >> >> >> On Oct 14, 2009, at 4:46 PM, Melton Low wrote: >> >> I am on a Mac laptop running Mac OS X 10.6.1 (Snow Leopard). >>> >>> Version of Sqlite I want to build is 3.6.19. When running >>> 'configure >>> --help' I didn't find an option to set the build to 32bit. Is >>> sqlite >>> automatically build as a 32bit app with 32bit libraries? Did I >>> miss an >>> option? >>> >>> Mel >>> ___ >>> sqlite-users mailing list >>> sqlite-users@sqlite.org >>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >>> >> >> - >> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> >> http://www.kyngchaos.com/ >> >> All generalizations are dangerous, even this one. >> >> >> > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." <Ha, ha> "And it might give 'em all stomach ulcers." - Tarzan, on war ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Mac OS Snow Leopard 32bit vs 64bit
Add this to your configure command (applies to most all configures): CFLAGS="-arch i386 -arch x86_64" On Oct 14, 2009, at 4:46 PM, Melton Low wrote: > I am on a Mac laptop running Mac OS X 10.6.1 (Snow Leopard). > > Version of Sqlite I want to build is 3.6.19. When running 'configure > --help' I didn't find an option to set the build to 32bit. Is sqlite > automatically build as a 32bit app with 32bit libraries? Did I miss > an > option? > > Mel > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Pre-compiled products
On Mar 23, 2009, at 12:11 AM, Jay A. Kreibich wrote: > Not exactly. A dylib doesn't know where it is, but it does like a > full path to the things it links to (i.e. libgcc, libSystem). You > can dig through the MachO header with otool(1). > > The big sticky point with dylib files vs ELF .so files is that Apple > provides no simple tool to re-write the paths inside the dylib file > (IIRC, libtool under Linux will do this). install_name_tool does this >> Using a static library means the sqlite program can be installed >> whereever the user likes, as long as they know how to run it (ie >> it's in >> their PATH). No admin permissions needed. > > Outside of the minor detail that Mach-O has no concept of a "static > library", There is static vs shared linking, at compile time. OSX does have both of these. There is also static vs dynamic loading, at run time. OSX can do both of these also. >> With a dylib, the program can still be anywhere, but the dylib >> needs to >> be where the program expects it, normally in /usr/local/lib, which >> needs >> admin permissions. Either a script to copy it there could work >> (again, >> there's the issue of us being Mac users), or a Mac installer >> package is >> needed. > > For stuff like this, I don't think anyone is expecting an installer. > If you need one, you should be using some kind of package management > system for installing SQLite. > > After all, neither the Windows SQLite3.DLL nor the Linux > libsqlite3.so > download distributions have any kind of install scripts-- the > downloads are just the raw library files. No reason for a Mac OS X > .dylib distribution to be any different than the Linux .so > distribution. > People either know what the files are and what to do with them, or > they're better off being confused. > OSX is OSX. Windows is Windows. Linux is Linux. The others may be simpler to allow just copying the binaries to wherever you like, but, in a default build at least, a library must be put in a particular place if you don't want to muck around with DYLD_LIBRARY_PATH. You could post-process the library with install_name_tool to make the program use a relative path - @executable_path/libsqlite.3.dylib - and then the program can be right next to the library. > BTW, part of the reason I'm asking these questions is that I'm trying > to write some docs having to do with the build/install process of > SQLite on different platforms. I've got a lot of UNIX experience, so > the Linux/Mac stuff is pretty easy, but I'm a bit of a newbie on > Windows. If there are any folks out there that have some cross > platform experience (i.e. speak UNIX) but spend a fair amount of time > under Windows, I'd love to hear from you. Well, if you're writing installation instructions, then that's simple - copy the program to whereever you like and use it. I don't think the binaries are intended for developer use of the library, no headers are included. So a shared library is not needed. - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Installing SQLite
On Mar 3, 2009, at 4:18 PM, D. Richard Hipp wrote: > Another issue, that I only discovered two days ago, is that binaries > compiled for Leopard (OS 10.5) will only run on Leopard and not older > OS X systems. And the precompiled shell found on the website is > compiled on Leopard (which is all I have at hand.) So downloading and > running the pre-compiled shell will not work unless you have the > latest Mac OS. I don't know how to fix this problem. Probably in the > next release we will just label the binaries as "Leopard or later > only". > > D. Richard Hipp > d...@hwaci.com The default deployment target on Leopard is Leopard. On earlier systems it's 10.3 (or 10.2?). To get a Tiger-compatible Sqlite built on Leopard: export MACOSX_DEPLOYMENT_TARGET=10.4 export CFLAGS="-Os -arch ppc -arch i386 -isysroot /Developer/SDKs/ MacOSX10.4u.sdk" then configure as you normally would. If you have the 10.3 SDK installed, you could go as far back as 10.3 deployment+SDK. - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Installing SQLite
Nothing wrong with Macs ;) As others have pointed out, OSX includes Sqlite, though a bit old. Also note that extension loading is disabled in this version. If you don't want to mess with installing Xcode, and want an up to date and feature-packed Sqlite installer, try my Sqlite framework. It includes most extra features available in the source, plus the Spatialite extension. Though it's made for building other applications with Sqlite support, the sqlite program is included (for use in Terminal.app). On Mar 3, 2009, at 9:48 AM, Dan M. Wall wrote: > > I am an experienced Windows user and application developer. I am > now attempting to actually use a Mac!! God forbid!! > > I have an SQLite database and I'm trying to figure out how to > install SQLite so I can view it and update it. I downloaded the bin > files but I'm obviously missing something. > > Please forgive my Mac OSX ignorance! Any help you can provide would > be greatly appreciated! > > Dan > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Xcode project for amalgamation
On Feb 23, 2009, at 9:15 AM, P Kishor wrote: > Ok, thanks William. I started again with BSD Dynamic Library template, > and this time I got only one error... a warning about an unused > variable 'err' on line 26510 of sqlite3.c. That line reads > > 26509> /* if mkdir fails, handle as lock file creation failure */ > 26510> int err = errno; > > (hence, cc-ing this message to the sqlite list) > unused vars - harmless. > But, it did build. Now, of course, since I asked for just a BSD > Dynamic Library, I got a libsqlite.dylib in the Products folder. I > didn't get my usual sqlite3 shell binary, so does that mean I have to > create another Xcode project with the Standard Command Line Tool > template for that? No, just make a new target in the project, BSD Shell Tool (and note the naming inconsistency - the other template called it "Standard Command Line Tool"). The template doesn't limit you to just the kind of binary it starts with. Add the sqlite executable source to this one, and drag in the sqlite library from the Products group to link them. For dependency sanity, drag the library target to the executable target also. This way all you need to build is the executable target, and that will automatically build the library target. Something like: libsqlite compile sqlite3.c sqlite libsqlite (target dependency) compile shell.c link libsqlite.dylib > Also, is there an equivalent of 'sudo make install' for Xcode that > actually files all the sqlite3 bits and bobs in the correct places? > I don't think so. There are some variables and steps mentioning installation, but I think that's only for: 1) linking (ie the install_name of a library) and 2) "installation" into the build products folder during compilation. Xcode is geared towards building Mac software, where it's a package, so "installation" is simply dragging the package to its destination. unix features seem to be for supporting Mac software. > Of course, I can do all this without any problem from the command > line, so this is more an exercise in learning Xcode. > Though doing it in Xcode means you can use the Xcode debugger, if you're interested in that. You can attach external executables to a project for use in the debugger, but they won't have a connection to their sources for easy access to fix a problem. Xcode has its uses in unix-based software, but it's hard to maintain synchronization with the source, especially on big projects like GRASS or where sources are added and deleted a lot. Optional components of a project can't be automated easily, there are no conditional targets in Xcode. Only code that is conditionalized on a macro can be made optional. I went Xcode crazy for a while with my frameworks and GRASS and Qgis, but quickly gave it up. Though I just became the maintainer of a new Xcode project in the Qgis source, we'll see how that goes... - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [sqlite-announce] SQLite version 3.6.7
On Dec 21, 2008, at 9:09 PM, Dan wrote: > I found I also needed: > > -DSQLITE_ENABLE_LOCKING_STYLE -D__DARWIN__ > > Dan. Huh, __DARWIN__ doesn't seem to be an OSX system macro. I wonder why __APPLE__ isn't used, I figured __DARWIN__ was set. And I missed SQLITE_ENABLE_LOCKING_STYLE in the compile options. Time to review the compile options ;) - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [sqlite-announce] SQLite version 3.6.7
On Dec 16, 2008, at 12:35 PM, D. Richard Hipp wrote: > Version 3.6.7 includes a major cleanup of the Unix driver in > os_unix.c. Also included is the new "Proxy Locking" locking module > for OSX. Proxy Locking provides greatly enhanced performance for > databases located on AFP filesystems. The Proxy Locking module is > turned off by default. > Finally got a chance to try this. When enabling the proxy locking (- DSQLITE_PREFER_PROXY_LOCKING) I get a compile error: sqlite3.c: In function 'unixOpen': sqlite3.c:25244: error: storage size of 'fsInfo' isn't known sqlite3.c:25252: error: 'MNT_LOCAL' undeclared (first use in this function) sqlite3.c:25252: error: (Each undeclared identifier is reported only once sqlite3.c:25252: error: for each function it appears in.) OSX 10.5.6, Xcode 3.1.2 - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] UTF8 support?
On Oct 27, 2008, at 10:23 AM, MikeW wrote: > William Kyngesburye <[EMAIL PROTECTED]> writes: > >> >> Does SQlite support UTF8 directly? Or is this what the ICU extension >> is for? Does the sqlite3 shell program support UTF8? >> >> There is this spatialite extension which includes a modified sqlite3 >> shell program that "implements full UNICODE support". So I'm a >> little >> confused. >> >> - >> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> >> > > Search the newsgroup ... start here: > http://thread.gmane.org/gmane.comp.db.sqlite.general/41826/focus=41843 > > Regards, > MikeW So, sqlite supports UTF8 directly - UTF8 in, UTF8 out. I suppose this applies to the shell program also? And then, ICU adds internal unicode sorting, searching and case conversion. The spatialite unicode support seems to be conversion routines to/from UTF8 in the shell when the shell uses some other encoding. I guess this doesn't worry me since OSX defaults to UTF8 in the shell, and I'm more interested in the library. I'll have to play with it a bit to see for sure. - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." <Ha, ha> "And it might give 'em all stomach ulcers." - Tarzan, on war ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] UTF8 support?
Does SQlite support UTF8 directly? Or is this what the ICU extension is for? Does the sqlite3 shell program support UTF8? There is this spatialite extension which includes a modified sqlite3 shell program that "implements full UNICODE support". So I'm a little confused. ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rtree cast warnings on 64bit OS - strange parameter use
On Oct 25, 2008, at 12:21 PM, Dan wrote: >> I thought the two pAux parameters were odd - one bare and one cast to >> (int), so I looked up rtreeInit(). > > Good point. I removed the first of the two "pAux" parameters from > rtreeInit(). It was not being used. > > http://www.sqlite.org/cvstrac/chngview?cn=5842 > Well, I only get one warning now, but at least I understand that it's expected, since you're not really using the pointer as a pointer. - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] rtree cast warnings on 64bit OS - strange parameter use
I added rtree to my sqlite compilation for the first time and got these warnings for OSX 64bit: /Users/Shared/src/sqlite/sqlite-3.6.4/sqlite3.c: In function ‘rtreeCreate’: /Users/Shared/src/sqlite/sqlite-3.6.4/sqlite3.c:94784: warning: cast from pointer to integer of different size /Users/Shared/src/sqlite/sqlite-3.6.4/sqlite3.c: In function ‘rtreeConnect’: /Users/Shared/src/sqlite/sqlite-3.6.4/sqlite3.c:94797: warning: cast from pointer to integer of different size These are in the rtreeCreate() and rtreeConnect() functions, calling rtreeInit(): return rtreeInit(db, pAux, argc, argv, ppVtab, pzErr, 1, (int)pAux); I thought the two pAux parameters were odd - one bare and one cast to (int), so I looked up rtreeInit(). static int rtreeInit(sqlite3 *db, void *pAux, int argc, const char *const*argv, sqlite3_vtab **ppVtab, char **pzErr, int isCreate, int eCoordType) The first pAux is a pointer, so this one looks correct. But the second is an int (eCoordType), and the only two values I found defined are 0 & 1: #define RTREE_COORD_REAL32 0 #define RTREE_COORD_INT32 1 Forget the cast warnings now - why is pAux used to set the eCoordType? My C skills are pretty basic, so maybe there is some pointer/cast magic happening? Or maybe it's simply screwed up? ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
