How does C/Invoke compare to libFFI?

At the C API level they're pretty similar, aside from some minor
quibbles. libFFI has been around longer and is much more portable, but
the last "release" was in 1998. An explanation why and the current
status of libFFI is detailed here:

The main difference from my POV is concentrating on interfacing with
existing languages so people don't have to write extension modules just
to call a few C functions. The current crop of interpreters (PHP, Perl,
Python, Ruby, Lua, Tcl, etc. etc.) aren't going anywhere anytime soon,
but if you're writing code in these languages and you happen to need
something quickly from C, you're faced with a disproportionate amount of
effort in terms of coding/building/distributing/etc. Writing things in
[insert language here] is supposed to be fast and easy.

So, the way we're attacking this is: 1) Design the C library to it's
easy to integrate with existing languages. 2) Actually implement
extension modules which provide P/Invoke-like interfaces on various
languages ourselves.

Parrot is a virtual machine with some similarities to Microsoft's .NET
Framework. In a sense, .NET, Parrot and C/Invoke are all trying to solve the
same problem, which is that the proliferation of new programming languages,
while providing developers with an indispensible variety of tools, has led to
a situation where the various environments are isolated from one another and
unable to easily share code. The result is duplication of effort, because
a useful library written for one language cannot be easily leveraged in another.
Parrot and .NET look to solve this by creating "universal" runtimes, thus
uniting all high-level languages on a single platform and creating opportunities
to interoperate. C/Invoke takes a different approach: integrating
with existing language interpreters and providing a simple bridge to C, a.k.a. the
"universal" low-level language. This approach is important because these interpreters
are already widely deployed and have such a large mass of code written for them,
whereas Parrot is not even a complete and usable system as of this writing.
However, it is this author's opinion that neither approach is "wrong", they
both can complement each other as we continue to build better interoperation
tools in the future.

Beyond this casual connection, it doesn't look like there is much opportunity
to unify C/Invoke and Parrot. Parrot has its own C interface
called NCI which is functionally similar to .NET's P/Invoke. While the
interface itself is not currently as mature as C/Invoke, it does have the
advantage of being implemented with Parrot's JIT compiler, which means it is
faster, easier to maintain, and (for the moment) more portable. Since NCI is strongly coupled to the Parrot
runtime, it seems as though the two projects should remain distinct. Perhaps
in the future if the Parrot developers can achieve their goal of having
at least most of the currently popular languages deployed on top of it, with
a sizable user base, then C/Invoke's usefulness will be diminished
substantially.