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.
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
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 try to mach the version from the OS, but that's a lot easier to say than accomplish.
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 I'm not sure about that might make that moot, In particular, anybody know what happens on OS X if you try to load two dylibs that define the same symbol? Even if I could get both libs to load, I'm not sure how it's going to differentiate the same functions from the two libs. Is it smart enough to remember which symbols came from which libs when the link occured? A variant on that is to statically link sqlite into the gem, but I'm still not sure about duplicate symbols ...
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 I'm not sure about that might make that moot, In particular, anybody know what happens on OS X if you try to load two dylibs that define the same symbol? Even if I could get both libs to load, I'm not sure how it's going to differentiate the same functions from the two libs. Is it smart enough to remember which symbols came from which libs when the link occured?
Indeed, that would be a problem. I believe there is a problem in the way CFNetwork uses sqlite3 here. It seems to prevent any user of Cocoa to use a different version of sqlite3. You should report it to Apple I think: http://bugreporter.apple.com.
A variant on that is to statically link sqlite into the gem, but I'm still not sure about duplicate symbols ...
That would be an idea. You can make sure the sqlite3 symbols will be stripped from the C extension binary by telling the linker (using for example -exported_symbols_list or -exported_symbols_list), this way they can't collide once the extension is dlopen'ed into the process using CFNetwork. Laurent
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 doesn't prohibit it, but it does raise the issue of whether the APIs are compatible. I'm also not sure what would happen under iOS where if you want to override sqlite, you have to do it statically (app store requirements) but if CFNetwork binds it dynamically ... I don't know enough about how the dl loader works.
You should report it to Apple I think: http://bugreporter.apple.com.
Honestly, feels kinda quixotic.
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
participants (2)
-
Laurent Sansonetti
-
Steven Parkes