ffi.loaders? (RE: How to properly ffi.load a .dll file)
- From: Stefano <phd.st.p@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 16 Mar 2015 18:58:17 +0000
On 7 Jun 2013 12:38, "William Adams" <william_a_adams
<william_a_adams@xxxxxxx>@ <william_a_adams@xxxxxxx>msn.com
<william_a_adams@xxxxxxx>> wrote:
>
> Thanks Mike. I'm currently doing GetModuleFilename, then using that
path. I'll keep doing that, perhaps adding a generalized module management
capability.
>
> Sent from my Windows Phone
> ________________________________
> From: Mike Pall
> Sent: 6/7/2013 4:10 AM
> To: luajit <luajit@xxxxxxxxxxxxx>@ <luajit@xxxxxxxxxxxxx>freelists.org
<luajit@xxxxxxxxxxxxx>
> Subject: Re: How to properly ffi.load a .dll file
>
> William Adams wrote:
> > Is there another way to do this? Some bit of information or
> > syntax I've missed such that this .dll file will be loaded with
> > ffi.load?
>
> Interstitial: Unix-based distros make a point in separating
> arch-independent and arch-specific files in the file system. Back
> then, this was about sharing partitions across machines (which is
> a non-issue with today's disk capacities). It still matters for
> cross-platform distros, since it allows them to keep the common,
> arch-independent files in a separate package.
>
> So, even though the norm on Windows is to put a DLL together with
> data or scripts, it causes problems: remember "Program Files" vs.
> "Program Files (x86)". Not pretty.
>
> To avoid this I'd use GetModuleFileName(NULL, ...) and ffi.arch
> and load the DLL relative to the executable with an absolute path.
> That would give you a layout like this:
>
> luajit.exe
> \dll\x86\sqlite3.dll
> \dll\x64\sqlite3.dll
> \lua\sqlite3.lua
>
> For a bigger project it might make sense to move the DLL
> resolving/loading functionality to a common module.
>
> --Mike
That's quite an old thread but anyway...this is similar to what I am doing
right now.
The problem is that in the case of Lua/CLua modules which are loaded via
require() I can just add a loader to package.loaders.
In the case of ffi.load() I would have either to modify each external
library code to use my custom loader instead of ffi.load(), which is
impractical, or to to monkey patch ffi.load() itself, which is not ideal.
I understand that the FFI is meant to be low-level and close to C, but
would a an addition among these lines be possible for LuaJIT 2.1?
Stefano
Other related posts:
