Tim Bunce wrote: > > Tim Bunce wrote: > > > > 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?
My bad. In my comments on Dan's blog, I confused libffi with ffcall. Both do roughly the same thing... The libffi was originally produced by Cygnus, but is now part of GCC. http://sources.redhat.com/libffi/ http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/LICENSE ffcall was produced by Bruno Haibel as part of his CLISP package. http://www.haible.de/bruno/packages-ffcall.html ffcall used to be considered more mature/stable, but since libffi was included in GCC the general impression true or not is that libffi is more actively maintained. From mailing lists and csv logs, it looks like both are actively maintained... -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
