<div dir="ltr">A quick look shows that it uses libffi, which doesn't work on iOS because of the way the stack is protected.<div><br></div><div style>-Jason</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Feb 27, 2013 at 9:29 AM, Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 2013-02-27, at 10:19 AM, Jason Felice <<a href="mailto:jason.m.felice@gmail.com">jason.m.felice@gmail.com</a>> wrote:<br>
<br>
> I'd be happy to unblackhole mine if it gets more people involved.<br>
><br>
> The x86_64 part is because ObjC doesn't provide a completely machine-abstract way to invoke dynamically.  Each way has some icky flaws.  My first goal was actually iOS, but I went down the x86_64 path because Mikael had a need for that first.  I'd like the package to have x86_64/i386/arm.<br>

><br>
> I did discover that a LOT more machinery is needed for x86_64 than for i386 or arm.  Calling conventions on 64-bit are crazy insane (though I now have the worst of it solved).<br>
<br>
</div>I agree that there are issues with all approaches.  If possible I'd like to avoid using assembly language which is compiler and operating system dependent (Objective-C runs on other platforms than iOS and OS X).<br>

<br>
I wonder if there are some ideas we can steal from the Python Objective-C bridge:<br>
<br>
  <a href="http://pythonhosted.org/pyobjc/" target="_blank">http://pythonhosted.org/pyobjc/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
Marc<br>
<br>
</font></span></blockquote></div><br></div>