True, waiting on Laurent for this may be the wrong approach. I have done a fair bit of my own investigation, and do not know where to go next, hence posting here.
In short, yes, Amalgalite uses and exposes more features of SQLite than are generally available from default builds, and even OSX's non-default build, hence embedding it in the ruby extension itself. To help, I would really like to understand the pros/cons of using flat vs. twolevel namespaces with respect to MacRuby and extensions. enjoy, -jeremy On Tue, Sep 13, 2011 at 12:11:06PM -0700, Jordan K. Hubbard wrote: > I'm not Laurent, but I'll also say that simply waiting for him to answer this > question may be the wrong approach. For one, the project (in order to truly > be successful) needs to move away from the "single point of failure" model > that over-reliance on Laurent has historically represented. This means that > it needs to grow some of its own talent and expertise and the "wait and see > what Laurent says" approach runs counter to this objective. Second, this may > be a problem that really needs to be addressed in the Amalgalite gem itself > since any component which ships with duplicate technology to what's in the OS > runs the risk of the same namespace (and other) conflicts. Are the > additional compile-time features really that important to the gem? > > Thanks, > > - Jordan > > On Sep 13, 2011, at 8:12 AM, Jeremy Hinegardner wrote: > > > Thanks, and lets hope Laurent can tell us what to do here :-). > > > > enjoy, > > > > -jeremy > > > > On Mon, Sep 12, 2011 at 07:39:37PM -0700, Matt Aimonetti wrote: > >> That's a good question, and honestly I have no idea :( > >> Laurent is on vacation so he's not checking the mailing list, but he should > >> be back soon and hopefully he will have an answer. > >> > >> - Matt > >> > >> On Mon, Sep 12, 2011 at 11:39 AM, Jeremy Hinegardner > >> <jer...@hinegardner.org > >>> wrote: > >> > >>> Hey all, > >>> > >>> I develop the Amalgalite gem[1] and it ships with its own copy of SQLite. > >>> It does this as it adds in additional compile-time features, and I try and > >>> keep it as current as posssible. > >>> > >>> The problem is that since MacRuby is linked to CoreServices etc, the > >>> sqlite > >>> library that ships with OSX gets linked at runtime before the sqlite > >>> library > >>> that is built into the amalgalite gem extension. I've encountered this > >>> before[2] with amalgalite, when it was loaded with my 'hitimes' gem (which > >>> on osx links > >>> against -framework CoreServes). > >>> > >>> I am wondering what the appropriate approach is here. I was able to fix > >>> this in > >>> MRI by compiling MRI with -twolevel_namespace and I think there is an open > >>> ticket > >>> with ruby-core to see if MRI on osx should be compiled with that flag. > >>> > >>> I attempted to compile MacRuby with -twolevel_namespace to resolve this, > >>> and I > >>> was unsuccessful. There appeared to be other flags that conflicted with > >>> it. > >>> > >>> I would expect something like this may also affect the nokogiri gem as > >>> limxml2 > >>> is also a system library on osx, and may conflict with the version that > >>> nokogiri > >>> expects. > >>> > >>> Thoughts? Opinions? I'm sure this is a rare case, Amalgalite may be the > >>> only > >>> project that could experience an issue like this. What is the best way to > >>> handle > >>> this in the MacRuby ecosystem? > >>> > >>> enjoy, > >>> > >>> -jeremy > >>> > >>> [1] - https://github.com/copiousfreetime/amalgalite > >>> [2] - > >>> https://github.com/copiousfreetime/amalgalite/blob/master/lib/amalgalite/sqlite3/version.rb#L42-L56-54 > >>> -- > >>> ======================================================================== > >>> Jeremy Hinegardner jer...@hinegardner.org > >>> > >>> _______________________________________________ > >>> MacRuby-devel mailing list > >>> MacRuby-devel@lists.macosforge.org > >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > >>> > > > > -- > > ======================================================================== > > Jeremy Hinegardner jer...@hinegardner.org > > > > _______________________________________________ > > MacRuby-devel mailing list > > MacRuby-devel@lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > -- ======================================================================== Jeremy Hinegardner jer...@hinegardner.org _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
