Re:

["Eric Tetz" <erictetz@...>]

On Dec 5, 2007 12:57 PM, Duck <duck@roaming.ath.cx> wrote:
> > Is it possible to have my app statically link to lua but also allow for DLL
> > based packages to work correctly?
>
> You need to build LUA.EXE with an export table for all of Lua's core and
> library API functions. Then you can build the DLLs you don't want to compile
> into LUA.EXE so that they import the Lua symbols from 
LUA.EXE, not from
> another DLL.

I have a similar situation, and it's painted me into a corner. Maybe you can help.

I wrote a Lua-to-exe converter ('luax') which works by packing an arbitrary list of files into the resource section of a statically linked interpreter. The interpreter automagically fetches files from within itself in response to Lua file routines -- open, loadlib, require, etc. -- so you can package your script and any additional scripts/files it needs into one, self-contained executable.

Luax.exe is itself a compiled script, containing luax.lua (front end), luax.dll (Lua lib for updating executable resources), and upx.exe (executable compressor). Luax compiles scripts by copying itself, replacing the resources in the copy, then compressing the result with upx.

Luax.dll is linked to the Lua API inside of luax.exe, exactly as you described. This works because luax.dll can rely on the name of it's host executable.

However, the executables that Luax outputs can have any name. This poses a problem if you want to include extension DLLs with your compiled script. Those DLLs have no way of knowing where to look for the Lua API.

I was thinking of rewriting the text inside the DLL at compiled time, so that it knows to look for your executable name, but that will still break if the user renames the executable after compilation.

Right now, the only solution I can think of is to:

(1) Create a proxy DLL that extension DLLs can link to. The proxy DLL would forward API calls to the host executable.
(2) Scrap my current system and have a stub that extracts an interpreter and an API DLL into a temp directory and runs them from there, so your extension DLLs can link directly to the API DLL.

I kinda like my current system because it's simple and doesn't *require* compiled scripts to create a temp directory at run time, but this DLL problem is a bit of a showstopper.

Cheers,
Eric