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 <jeremy@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/sql... -- ======================================================================== Jeremy Hinegardner jeremy@hinegardner.org
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
-- ======================================================================== Jeremy Hinegardner jeremy@hinegardner.org
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel