On Sat, Jan 10, 2004 at 09:42:14PM +0000, Tim Bunce wrote: > On Sat, Jan 10, 2004 at 08:31:21PM +0100, Leopold Toetsch wrote: > > Jeff Clites <[EMAIL PROTECTED]> wrote: > > > > > I assume the plan is to get on-the-fly building of NCI stubs working > > > "everywhere". Platforms where that works don't need the functions > > > generated by build_nativecall.pl, but right now that's only i386; it's > > > a JIT-like and pretty difficult piece of code to write, but it should > > > eventually work on every platform which supports JIT, at least. > > > > It looks like, that we can't get each possible permutation of signatures > > built statically. This would also boost executable size beyond any > > reasonable limits. > > > > "I'ts a JIT-like" code but its not too difficult to implement and > > indpendent of JIT is implemented. It just needs a bit of knowledge of > > the architectures ABI (how functions get their params and return these) > > and of course how to implement that. I'm really not an assembly code > > hacker, but JITted NIC for i386 was implemented really quickly. > > I see Dan says in his blog "Yeah, I know, we should use libffi, and > we may as a fallback, if we don't just give in and build up the > function headers everywhere." > > I'm not familiar with libffi so this may be a dumb question, > but why the apparent reluctance to use it?
In http://www.nntp.perl.org/group/perl.perl6.internals/253 I see Garrett Goebel quotes Bruno Haible saying "I could agree to the LGPL license. Perl could then use ffcall as a shared library (linked or via dlopen)" And I see http://www.parrotcode.org/docs/faq.pod.html says "Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this." So it seems there's no licensing issue preventing parrot using libffi. Is that right? Are there any others? Tim.
