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 those I can still do with 1.8/1.9 (so far, anyway). On Sep 13, 2010, at 8:56 PM, Laurent Sansonetti wrote:
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?
Laurent
On Sep 12, 2010, at 3:49 PM, Steven Parkes wrote:
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 macruby doesn't link to any sqlite, CFNetwork does, and it links against the the system version. That link gets resolved before the gem extension is loaded, so the system version is used.
I don't have much experience with dylibs on OS X, so I'm not sure if there's a good workaround for this.
I can hack a workaround by actually calling out sqlite3 on the macruby link line and telling it to look at the maports version. That gets loaded before the framework stuff and everything seems happy.
But, it's gross, of course.
Ugh. _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel