Re: Using FFI as a plugin
- From: Coda Highland <chighland@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Thu, 17 May 2012 12:27:40 -0500
On Thu, May 17, 2012 at 12:25 PM, Dimiter 'malkia' Stanev
<malkia@xxxxxxxxx> wrote:
> On 5/17/2012 9:44 AM, Coda Highland wrote:
>
> My program is a plugin loaded into an external host, and I've
> discovered that the FFI is unable to resolve symbols defined in it
> because the host (for obvious reasons) doesn't load the plugin into
> the global symbol namespace.
>
> Is there a way around this while still using the FFI? Perhaps a way to
> provide an explicit function pointer instead of relying on
> dlsym/GetProcAddress? I'd like to avoid the overhead and performance
> hit of wrapping all of my functions in Lua_CFunctions if at all
> possible.
>
> /s/ Adam
>
>
> Now ffi.load allows you to specify whether the stuff you load goes into
> local/global namespace,
> but I guess you are talking about the ffi.C where the crt and other libs are
> loaded?
> Maybe you can load them additionally ffi.load( "c" ) /* libc */?
>
> I'm also interested of possible variants to provide alternatives to
> dlsym/GetProcAddress(), as I'm
> looking for workarounds for the cases where I can't ship additional
> .dll/.dylib/.so files.
>
> Here is ffi.load() usage:
>
> clib = ffi.load(name [,global])
>
> This loads the dynamic library given by name and returns a new C library
> namespace which binds to its symbols. On POSIX systems, if global is true,
> the library symbols are loaded into the global namespace, too.
>
> If name is a path, the library is loaded from this path. Otherwise name is
> canonicalized in a system-dependent way and searched in the default search
> path for dynamic libraries:
>
> On POSIX systems, if the name contains no dot, the extension .so is
> appended. Also, the lib prefix is prepended if necessary.
> So ffi.load("z") looks for "libz.so" in the default shared library search
> path.
>
> On Windows systems, if the name contains no dot, the extension .dll is
> appended. Soffi.load("ws2_32") looks for "ws2_32.dll" in the default DLL
> search path.
>
Yes, I had considered this, but that requires knowing exactly where
the host decided to install my plugin, which can and will vary from
system to system. If the plugin could somehow resolve its own path,
that would do the trick, but at present I don't think there's a way to
do that.
/s/ Adam
Other related posts:
