This is probably a completely obvious answer, however I have a version of
CLisp and when I (compile-file <blah>) It goes, ok, smashing great super
etc. and it gives me a .fas file, how do i make this executable
Thanks
Fin
·············@orca.ucd.ie
In <··········@hermes.ucd.ie>, ········@orca.ucd.ie (Finbarr O'Kane) writes:
>This is probably a completely obvious answer, however I have a version of
>CLisp and when I (compile-file <blah>) It goes, ok, smashing great super
>etc. and it gives me a .fas file, how do i make this executable
>
>Thanks
>Fin
>
>·············@orca.ucd.ie
>
You can't this file must be interpreted by CLISP (it's a kind of pseudocode).
If you really want executables without the LISP system , try ecl , which is
a variant of AKCL , the code produced can be linked in a C program.
Mertens Marc
·······@ibm.net
In article <···········@news-s01.ny.us.ibm.net> ·······@ibm.net writes:
>
>If you really want executables without the LISP system , try ecl , which is
>a variant of AKCL , the code produced can be linked in a C program.
>
This ecl sounds way cool, and yet I don't think I've ever heard of it.
Can anyone tell me more about it? Where to get it?
-- jeff
Finbarr O'Kane <········@orca.ucd.ie> asked:
>
> ... CLisp and when I (compile-file <blah>) It goes, ok, smashing great super
> etc. and it gives me a .fas file, how do i make this executable
Unix specific answer: Install the small "clispsh" package from
ma2s2.mathematik.uni-karlsruhe.de:/pub/lisp/clisp/packages/clispsh.tar.z
and add the following line at the top of your .lsp or .fas file:
#!/usr/local/bin/clispsh
Now you can call your Lisp file as if it were an executable. The real
executable is still the clisp binary, however.
Bruno Haible email: <······@ilog.fr>
Software Engineer phone: +33-1-49083585
There has been a number of question about compiling Lisp files to get
stand alone executables. I will attempt to present the main options.
Summary:
There are two general ways to create stand-alone executables from
Lisp: dumping and translation. Dumping is the usual technique and if
you're just trying to get something done quickly, I suggest you limit
yourself to this.
First I will describe dumping, then translation in general, and then
some specific translation implementations available. If you are very
interested in translation, I urge you to locate the "Future of Lisp?
(survey)" thread in this newsgroup and e-mail in your interest in
improving application delivery.
----------------------
DUMPING. This generates an executable (sometimes called an "image",
"environment", "world" or "band") that contains your entire Lisp
environemnt PLUS your application. The usual technique is:
1. Compile-file all the files you need.
2. Exit and restart your Lisp environment.
3. Load your previously compiled files.
4. Dump memory to disk using some function that varies from system to
system. (Not all systems have it. Try (apropos "DUMP"), (apropos
"SAVE"). This will create an executable which you start up
instead of your usual Lisp environment.
5. You need to find some way to have this new Lisp environment start
up by calling the function which begins your application. Again
this varies with different systems. Common possibilities are:
a. A command line argument.
b. Call the function in an initialization file which your
implementation always loads at start up.
c. There may be an option on the dumping function which causes
some form to evaluated at startup in the newly created lisp.
A variation on this is tree-shaking, in which the dumping program
tries to get rid of everything which your applciation doesn't use.
Tree-shakers are sometimes offered by the commercial vendors.
TRANSLATION. Your code is translated by a compiler to C source code
(How's that for broken terminology!) which is then compiled to
object files and linked to a run time library. In more detail:
1. "Compile" your files to C, and thence to object files.
2. A main() must be created which initializes the various things:
a. The garbage collector must be initialized.
b. When a Lisp file is compiled, it creates two sets of code to be
executed:
- the instructions which form the body of each function
- the initialization of all the data structures which are used
by that code. This includes such things as interning symbols
and setting their symbol-value and symbol-function.
This initialization is usually performed when the compiled
"binary" is loaded. Your main() will have to call this
initialization code not only for your compiled files, but for
potentially ALL the functions in your Lisp implementation.
c. It must call the function which starts your application, and
pass it the correct arguments. There are several tricky parts
to this:
- Most "compile-to-C" Lisps use indeciferable names. You need to
find the one which corresponds to the function you want to
call.
- Even when you find it, you must be certain that there are no
other functions with the same name in the files you compiled
(otherwise you won't be able to link them). I think you will
discover that most "compile-to-C" Lisps reuse the same names.
Perhaps there is something you can do to avoid this, such as
putting your entire application into one big source file.
- You will find that most "compile-to-C" Lisps do not use the
usual C argument passing techniques, and instead pass
arguments on a separate Lisp-data stack. I do not remember if
this is the case with GCL. ECL does use a "normal" C call
mechanism, except that the first argument is an int indicating
the number of arguments. If your Lisp uses a Lisp-data stack,
you will have to figure out how to gain access to that stack.
- You will have to figure out how to create Lisp objects to pass
as arguments. Most Lisps have some sort of foreign-function
interface which provides some means of creating Lisp objects
from C. You may be able to avoid this problem by starting your
application with a dummy function which takes no arguments and
then calls your real function.
3. Now you must figure out how to link up your object files, the file
which contains main(), and all the relevent object library files
containing the definitions of Lisp functions. Now, here's the
killer. I beleive that most "compile-to-C" lisps such as GCL and
ECL do not define a random access library with all Lisp
definitions. Instead you will have to link-in all the files. Now
you're not any better off than if you had just used the dumping
technique to begin with. Even if there is a random access
library, in general, the initialization of data in step 2.C.
probably "touches" all the functions in the system anyway.
Chestnut Software had a very expensive Lisp-to-C translator which did
this. Unfortunately, they are now gone.
There is a university project in Germany called CLiCC which does this
for free on certain classes of programs written in a subset of Common
Lisp. Last I looked it was at:
ftp.informatik.uni-kiel.de:/pub/kiel/apply/clicc-0.6.4.tar.gz Can
anyone report on how sucessful this has been on generating real-world,
small stand-alone executables? Wolfgang? Ulrich?
I believe ECL suffers from most of the same issues above as GCL with
respect to generating small executables. However, it might be easier
to call Lisp from C than in GCL. Giuseppe? It has been at:
ftp.di.unipi.it:/pub/lang/lisp/ecl-??.tar.gz or
ftp.icsi.berkeley.edu:/pub/ai/ecl/ecl-??.tar.gz.
I'm interested in developing technologies to do this. If anyone else
is, please contact me.