[Mono-dev] libffi

[Jonathan Pryor]

On Dec 13, 2010, at 7:08 PM, Charles Strahan wrote:
> If I understand correctly, we'd have two options for using DLLImport:

I am missing some important context, so I don't understand what you want to accomplish, what the problems are, and thus what the "best" way to do it is.  As per my original response, libffi was removed from mono for performance reasons, and it is thus unlikely to return.

I do not know or understand the semantics of RubyFFI, how it's similar to libffi & P/Invoke, and how it differs from P/Invoke, much less how to map RubyFFI use to P/Invoke use (if that's even desirable; again, I have no idea).

>  1.) Emit classes at runtime, containing the necessary native
> function adorned with the DLLImport attribute.

I can't say if this would work for _you_, but I can say that this can work in general; see:

	https://github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/CdeclFunction.cs

>  2.) Use DLLImport/PInvoke to provide access to
> dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
> load DLLs and invoke their functions.

This seems silly, given that [DllImport] & P/Invoke are built upon dlopen+dlsym/LoadLibrary+GetProcAddress; I do not see the point.

 - Jon