Re: FW: srlua extension to run with glued zip file

[Jay Carlson <nop@...>]

duck wrote:
> > I've now a basic extension to srlua running which allows you to combine 
> > multiple (lua-) files in one zip file and than start it as a standalone 
> > executable.
>
>
> Great idea (if the amount the Lua code -- and you can precompile it, of 
> course, to save space -- compresses is larger than the size of the 
> decompressor...).
>
> Another way to do this on Windows would be to embed the "glued" codes
> as resource entries (so they are inside the EXE proper) and then to UPX 
> the whole file. (UPX is a run-time in-memory unpackaging system. Highly 
> recommended to impress your friends when showing them how small your
> Lua run-time is compared to their Perl or Python distro. The UPX 
> decompressor is very small.)
>
> Has anyone tried using UPX for this (and is there an analogous way to 
> embed binary data into ELF binaries so that the original executable is 
> unaffected but the embedded data in technically "inside" as far as 
> exectuable packers are concerned)?

I'm confused.  Why don't you just use the linker to put in the data that 
you want?  The most portable way to do this is just stuff everything 
into a const char[] and compile it.  If you want to skip the 
octets->.c->.o overhead I suppose you could use objcopy to go directly 
from octets->.o, or use a linker script for more control.

If the goal is to avoid having the whole development environment 
including headers on the machine performing the append, then ship a 
partially linked version of the lua executable with a weak symbol that 
will be supplied by the .o containing the octets.  The target machine 
then just needs objcopy and a linker.

If you can't depend on having a linker on the target machine, yeah, 
you're going to have to play around with libelf like lhf says.  But just 
about everybody has a linker.

Jay