|Linking scripts and interpreters into an executable email@example.com (Juergen Kahrs) (1998-07-30)|
|Re: Linking scripts and interpreters into an executable firstname.lastname@example.org (Ray Pereda) (1998-08-10)|
|Re: Linking scripts and interpreters into an executable Juergen.Kahrs@t-online.de (1998-08-10)|
|Re: Linking scripts and interpreters into an executable email@example.com (1998-08-13)|
|Re: Linking scripts and interpreters into an executable firstname.lastname@example.org (1998-08-13)|
|Re: Linking scripts and interpreters into an executable email@example.com (Tony Bass) (1998-08-16)|
|Re: Linking scripts and interpreters into an executable firstname.lastname@example.org (Juergen Kahrs) (1998-08-17)|
|From:||Tony Bass <email@example.com>|
|Date:||16 Aug 1998 22:39:17 -0400|
|References:||98-07-238 98-08-046 98-08-080|
> On Thu, 30 Jul 1998, Juergen Kahrs wrote:
> >> not have an option for (statically) linking scripts (shell, AWK, Perl)
> >> together with their interpreters into an executable.
> >> Does anyone know of a linker which can do this ?
> Ray Pereda mumbled something about
> RP> I have not seen explicit support for this kind of feature but I think
> RP> it is much needed. Most executable file formats have a non-executable,
> RP> non-program data section. I would dump the script in there.
caml-light uses a technique assuming that the architecture's ordinary
format for executable files allows and ignores information appended at
the end. The caml-light linker writes an executable file containing
the run-time interpreter and then the caml-light byte-code, ending
with a small index table at the very end giving two or three vital
entry points. When run the interpreter's main() looks at the end of
its executable file, and if it finds a suitable bytecode index table
it starts interpreting the bytecode.
The caml-light linker also allows construction of an extended
interpreter executable linking in a user's additional C routines, so
one can in effect add to the available primitives.
Perhaps not entirely portable in theory, but in practice on a
particular Unix it seems thoroughly usable and convenient.
# A E Bass Tel: (01473) 645305
# MLB 3/19, BT Laboratories e-mail: firstname.lastname@example.org
# Martlesham Heath, Ipswich, Suffolk, IP5 3RE Do not rely on From: line
Return to the
Search the comp.compilers archives again.