On Mon, Jan 12, 2004 at 01:01:58PM -0600, Garrett Goebel wrote: > 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...
And since it seems both are usable for parrot from a licencing perspective we're free to use whichever suits best on a given platform - assuming someone implements the relevant interface code. Tim.
