-twolevel_namespace issue?
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
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
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
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
At 12:11 PM -0700 9/13/11, 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.
+1
For one, the project (in order to truly be successful) needs to move away from the "single point of failure" model ...
More generally, to be a full-fledged Open Source project, it needs to build up a body of developers outside of Apple. (Of course, Darwin itself largely fails that standard, but that's not the problem at hand. :-).
Second, this may be a problem that really needs to be addressed in the Amalgalite gem itself ...
And gaining knowledge of how to handle this sort of issue is also necessary to the development, deployment, and maintenance of MacRuby. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation
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 <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
-- ======================================================================== Jeremy Hinegardner jeremy@hinegardner.org
I think it would be easier to collaborate on a project like this if we had a good forum - where threads can be sticked, announcements be posted etc It's one of the things I miss from the PHP world, where there are lots of communities using forums very effectively. From support to collaboration, to just getting to know each other. I actually came to Ruby (Rails) so I could move away from forum-based sites (which I've been into for years) but I'd be willing to do one last one for Ruby if enough people wanted it - we could have separate categories for projects like MacRuby, Rails, etc, with their respective leaders having mod permissions to post announcements/stick threads etc (but the low level 'spam' moderating etc would be left to me and my mod team. Does that interest anyone? Aston On 13 Sep 2011, at 21:37, Jeremy Hinegardner wrote:
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 <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
-- ======================================================================== Jeremy Hinegardner jeremy@hinegardner.org
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
That'd be great Aston. Thanks, - Matt On Tue, Sep 13, 2011 at 2:59 PM, azzzz@gmx.net <azzzz@gmx.net> wrote:
I think it would be easier to collaborate on a project like this if we had a good forum - where threads can be sticked, announcements be posted etc
It's one of the things I miss from the PHP world, where there are lots of communities using forums very effectively. From support to collaboration, to just getting to know each other.
I actually came to Ruby (Rails) so I could move away from forum-based sites (which I've been into for years) but I'd be willing to do one last one for Ruby if enough people wanted it - we could have separate categories for projects like MacRuby, Rails, etc, with their respective leaders having mod permissions to post announcements/stick threads etc (but the low level 'spam' moderating etc would be left to me and my mod team.
Does that interest anyone?
Aston
On 13 Sep 2011, at 21:37, Jeremy Hinegardner wrote:
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 < 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
-- ======================================================================== Jeremy Hinegardner jeremy@hinegardner.org
_______________________________________________ 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
Hi Jeremy, Could the problem be fixed by linking statically your own copy of SQLite against the Amalgalite library, and perhaps passing all SQLite symbols to -unexported_symbols_list during ld time? I am guessing symbols wouldn't collide anymore this way.
From what I understand, it looks like it would be better to fix the problem in Amalgalite itself, and not in each client requiring it.
Laurent On Mon, Sep 12, 2011 at 8:39 PM, 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
I will see if that can work. So the approache would be to statically compile the sqlite lib that ships with amalgalite, and separately link it to the extension vs. compiling it all together as it does today. I will give those options a try and see who it all works. Thanks for the info, compiler flags and linking options are not my forte. -jeremy On Sun, Sep 18, 2011 at 11:10:49AM +0200, Laurent Sansonetti wrote:
Hi Jeremy,
Could the problem be fixed by linking statically your own copy of SQLite against the Amalgalite library, and perhaps passing all SQLite symbols to -unexported_symbols_list during ld time? I am guessing symbols wouldn't collide anymore this way.
From what I understand, it looks like it would be better to fix the problem in Amalgalite itself, and not in each client requiring it.
Laurent
On Mon, Sep 12, 2011 at 8:39 PM, 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
participants (6)
-
azzzz＠gmx.net
-
Jeremy Hinegardner
-
Jordan K. Hubbard
-
Laurent Sansonetti
-
Matt Aimonetti
-
Rich Morin