> I believe there is a problem in the way CFNetwork uses sqlite3 here.
C.f. http://arstechnica.com/civis/viewtopic.php?f=19&t=115763&start=280: i.e.,
CFNetwork/CFURL/NSURL use sqlite to cache responses.
> It seems to prevent any user of Cocoa to use a different version of sqlite3.
Well, it does
On Sep 14, 2010, at 6:44 AM, Steven Parkes wrote:
>> Did you try renaming the sqlite3 macports library name, or toggle the
>> options passed to the linker when creating the library?
>
> I haven't yet. It was something I thought about, but there are a couple of
> things about dylibs on OS X that
As a quick follow up, I realized that since the focus of my macruby stuff is
cocoa apps which I compile into mach executables avoiding the macruby
executable, I have the opportunity to (and, actually, must) add the custom
sqlite there. Doesn't work for CLI apps that run against macruby, but thos
> I'm not even sure loading the sqlite3 macports version first is a good idea,
> since CFNetwork might not work with that version.
Yeah, I thought about that. One would hope that sqlite3 is pretty
consistent/upgradable within minor versions at this point, but there's no
guarantee. One could tr
Hi Steven,
I see, that's a problem indeed. I'm not even sure loading the sqlite3 macports
version first is a good idea, since CFNetwork might not work with that version.
Did you try renaming the sqlite3 macports library name, or toggle the options
passed to the linker when creating the library
Ugh. The sqlite that ships with OS X doesn't have the full text search module
enabled. This isn't usually a problem: just install a custom version, e.g., via
macports, and then (re)install the sqlite3 gem. Works great for 1.8/1.9.
Fails miserably for macruby.
I think the problem is that while m
