From: Deepak Goel
Subject: compiling lisp files into executables..
Date: 
Message-ID: <Pine.GSO.4.10.9908261837350.29071-100000@fosters.umd.edu>
hi

i(am a novice and) was hopin gto create a stand-alone-executable out of
my lisp program. 

am usign franz lisp. 

(compile-file ..) created a .fasl file which however has to be called from
within lisp...

how do i create a stand-alone executable file?


--Deepak

From: Erik Naggum
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <3144699798418751@naggum.no>
* Deepak Goel <·····@Glue.umd.edu>
| i (am a novice and) was hoping to create a stand-alone executable out of
| my lisp program.

  why?  are you going to deploy it on a matchbox-size robot or something?

  seriously, you should investigate your real need, not reach for the
  hammer because you have only seen nails so far.

| am using franz lisp. 

  that's quite impressive if true.  are you sure you are not using Franz
  Inc's Allegro Common Lisp?  I'm assuming you mean ACL 5.0.1.

| (compile-file ..) created a .fasl file which however has to be called
| from within lisp...

  well, loaded, yes.  why is that a problem?  you will hardly find any
  program that is truly standalone these days.  most of them load all kinds
  of shared libraries and use a whole lot of operating system resources,
  except they have probably concealed it so it isn't obvious to the novice.

| how do i create a stand-alone executable file?

(with-open-file (executable "whatever" :direction :output)
  (format executable "#!/bin/sh~%lisp -qq -L whatever.fasl -e '(whatever)'~%"))
(excl:run-shell-command "chmod +x whatever")

  there are more complex ways that produce image files (.dxl) and which may
  be dedicated to a particular task different from development (runtimes).
  if you have an image whatever.dxl, you can even link "lisp" to "whatever"
  and it will search for whatever.dxl first.  there is also a shared
  library that is probably needed unless the image is dumped standalone.

  none of this is going to make much sense as advise goes, however, until I
  know more about your actual need, as opposed to the perceived need for a
  stand-alone executable in a world where that is actually so uncommon that
  only the impression that it is what you get is what remains.

  fitting Lisp applications into the Unix world is pretty easy, but you
  lose about 90% of the value of Lisp applications when you do that.  if
  you actually want to increase the value of your Unix system by adding
  Lisp applications to it, you're better off turning your world upside down
  and investigating how to run Unix programs smoothly from inside your Lisp
  application.  it's almost like they do under Windows: just let your
  application (riding on top of Allegro CL) take over the whole machine --
  it's better off without the silly operating system, anyway.

#:Erik
-- 
  save the children: just say NO to sex with pro-lifers
From: Barry Margolin
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <Yqkx3.464$m84.8050@burlma1-snr2>
In article <················@naggum.no>, Erik Naggum  <····@naggum.no> wrote:
>  none of this is going to make much sense as advise goes, however, until I
>  know more about your actual need, as opposed to the perceived need for a
>  stand-alone executable in a world where that is actually so uncommon that
>  only the impression that it is what you get is what remains.

Huh?  Standalone executables are the norm in Unix?  You type a command name
at the shell prompt, the system loads that executable into memory, and runs
it.  Why is it so hard to understand writing the program in Lisp to create
that executable?

I don't know the specifics for ACL (or any other Lisp, for that matter),
but in general you load the fasl file into Lisp, you use an
implementation-dependent function to save an image file, and this function
usually has a parameter where you specify a function to be executed as the
"main program" when the image is started back up.  Check your manual, it
should be explained pretty well there.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Erik Naggum
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <3144704433503797@naggum.no>
* Barry Margolin <······@bbnplanet.com>
| Huh?  Standalone executables are the norm in Unix?

  I'm not quite sure what you are replying to, but I'm arguing that only
  the _impression_ that programs are _stand-alone_ executables remains --
  the reality is very little under Unix is actually stand-alone in any way
  that it makes sense to continue to call it.

| You type a command name at the shell prompt, the system loads that
| executable into memory, and runs it.  Why is it so hard to understand
| writing the program in Lisp to create that executable?

  did you see the question I answered?  why does it matter whether it is
  _stand-alone_?  why is the user unhappy that there are shared libraries,
  .fasl files to load (automatically!), etc?  you seem to argue as if I had
  argued against making executables.  I haven't.  I have argued against the
  very silly notion that today's executables are stand-alone, because they
  aren't.  only the terminology remains.

| I don't know the specifics for ACL (or any other Lisp, for that matter),
| but in general you load the fasl file into Lisp, you use an
| implementation- dependent function to save an image file, and this
| function usually has a parameter where you specify a function to be
| executed as the "main program" when the image is started back up.  Check
| your manual, it should be explained pretty well there.

  I would have thought this would be sufficient, too, but let's consider
  the case where this dumping of an image file creates _two_ files.  one is
  a simple (symbolic) link to the runtime system loader (including a big
  shared library), and the other is an image file selected automatically
  according to the name of the actual executable file you invoked.  this is
  not a stand-alone executable.  it _is_ an executable program invokable
  from the command-line like all other Unix programs, however.

  for the purposes of creating even more arguments against something I have
  explicitly said I don't mean, let me be specific: I think creating small
  "executables" is a meaningless exercise.  I think having a means to make
  each individual, incremental program small is very beneficial.  to this
  end, I don't think loading a .fasl file at startup is a big deal, but
  some others seem to think not having the actual code in the _first_ file
  loaded when the program starts running somehow defeats the concept of
  "executable".  e.g., I'd be delighted if .fasl files were "executable" in
  the sense that they had "x" permission bits and could load their Lisp
  environment on their own, if that's all it takes to satisfy the concept
  of "executable" implied by "the file with the name I invoke" idea.

#:Erik
-- 
  save the children: just say NO to sex with pro-lifers
From: Rainer Joswig
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <joswig-2708991227120001@pbg3.lavielle.com>
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:

> Erik Naggum <····@naggum.no> writes:
> 
> >  e.g., I'd be delighted if .fasl files were "executable" in
> >   the sense that they had "x" permission bits and could load their Lisp
> >   environment on their own, if that's all it takes to satisfy the concept
> >   of "executable" implied by "the file with the name I invoke" idea.
> 
> Why not?  This works at least on some architectures:

When you open a Macintosh Common Lisp "fasl" file
(for example by a double click on the icon) the MacOS let
a running Lisp load the fasl or (if none is running)
starts a new Lisp and which then loads the fasl.
From: Martin Cracauer
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <7qddh0$2qpk$1@counter.bik-gmbh.de>
······@lavielle.com (Rainer Joswig) writes:

>In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:

>> Erik Naggum <····@naggum.no> writes:
>> 
>> >  e.g., I'd be delighted if .fasl files were "executable" in
>> >   the sense that they had "x" permission bits and could load their Lisp
>> >   environment on their own, if that's all it takes to satisfy the concept
>> >   of "executable" implied by "the file with the name I invoke" idea.
>> 
>> Why not?  This works at least on some architectures:

>When you open a Macintosh Common Lisp "fasl" file
>(for example by a double click on the icon) the MacOS let
>a running Lisp load the fasl or (if none is running)
>starts a new Lisp and which then loads the fasl.

The Linux kernel has hooks to add binary types, so that you could have
a compiled Lisp file (or core file) and just call it like any C
program. The only thing needed is a fixed magic number at the start of
the file.

FreeBSD doesn't have this capability, as it seems most useless as you
could just create a little script like this:

#! /bin/sh
exec lisp -eval '(load "foo") (main) (quit)'
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar 
 program on a junk operating system, eh?
From: Peter Van Eynde
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <slrn7sl5ol.sju.pvaneynd@mail.inthan.be>
On 30 Aug 1999 09:57:20 +0200, Martin Cracauer wrote:
>>When you open a Macintosh Common Lisp "fasl" file
>>(for example by a double click on the icon) the MacOS let
>>a running Lisp load the fasl or (if none is running)
>>starts a new Lisp and which then loads the fasl.
>
>The Linux kernel has hooks to add binary types, so that you could have
>a compiled Lisp file (or core file) and just call it like any C
>program. The only thing needed is a fixed magic number at the start of
>the file.

Or a unique file extension. 

Groetjes, Peter

-- 
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?" - Pitr| ········@inthan.be for more pleasure!
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd
From: Howard R. Stearns
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <37CA9ECE.953172AE@elwood.com>
Robert Monfera wrote:
> ...
> Maybe we need to say this, or have a FAQ entry for this, otherwise
> newcomers get the wrong impression just because they use the word
> 'standalone' not in the literal sense, but rather to imply things like:
> ...

I agree.  I think that there are several levels of explanation that
should be offered:

1. Conceptual, without going into details of specific operating systems
or Lisp implementations.  http://www.lisp.org has a section called "What
is Lisp?" that I think is the proper home for this level of
explanation.  For example, it has entries about compile/interpret,
static/weak typing, and other common confusions.  See, for example:
http://www.elwood.com/alu/table/lisp.htm

Would any of you pundits like to take a stab at writing this?  We can
try an experiment.  Someone can submit a draft to this newsgroup and
incorporate feedback.  If you hate the idea of "authorship by committee"
from such a large committee, (as I tend to feel,) then you can use a
smaller group and just send the results to me for final editing and
inclusion on the web site.

As always, I welcome comments about the existing material. Just remember
that this isn't meant to be the final authoritive word, just a place
where people can go to get a useful and brief introduction which they
can then use as a basis for understanding more specific implementation-
and application-specific possibilities.

2. Specific common solutions.  This should go in the FAQ.  Barry, are
you maintaining the FAQ?  Would it be possible for you to enumerate some
of the suggestions posted here?  Topic 2-11 address saving a Lisp image,
but this could be extended to the other ways of making "an executable". 
To make it easy, lets presume the existence of a suitable conceptual
overview at www.lisp.org.

3. Specific supported solutions.  This is the province of the vendors.
From: Deepak Goel
Subject: compiling lisp files into executables..
Date: 
Message-ID: <Pine.GSO.4.10.9908301528430.16426-100000@fosters.umd.edu>
thanks everyone for the replies.

U r right, novices like me use the word 'standalone' and try to imply
something else.

(yes it's indeed Franz's Allegro common lisp 5.0.1 that i am usign)

what i was wanted to have was: compile my program into one (or 2 or 3)
file(s) that can then be executed by typing a single command, and that
such a file, when ftp'ed to a different unix system, would 'run' there as
well, without the user having to know how to start lisp there on that
particular unix machine..

that's what my perception of a 'binary standalone executable' is..
 (or used to be).

any suggstions u care to make?


On Mon, 30 Aug 1999, Howard R. Stearns wrote:

> Robert Monfera wrote:
> > ...
> > Maybe we need to say this, or have a FAQ entry for this, otherwise
> > newcomers get the wrong impression just because they use the word
> > 'standalone' not in the literal sense, but rather to imply things like:
> > ...
> 
> I agree.  I think that there are several levels of explanation that
> should be offered:
> 
> 1. Conceptual, without going into details of specific operating systems
> or Lisp implementations.  http://www.lisp.org has a section called "What
> is Lisp?" that I think is the proper home for this level of
> explanation.  For example, it has entries about compile/interpret,
> static/weak typing, and other common confusions.  See, for example:
> http://www.elwood.com/alu/table/lisp.htm
> 
> Would any of you pundits like to take a stab at writing this?  We can
> try an experiment.  Someone can submit a draft to this newsgroup and
> incorporate feedback.  If you hate the idea of "authorship by committee"
> from such a large committee, (as I tend to feel,) then you can use a
> smaller group and just send the results to me for final editing and
> inclusion on the web site.
> 
> As always, I welcome comments about the existing material. Just remember
> that this isn't meant to be the final authoritive word, just a place
> where people can go to get a useful and brief introduction which they
> can then use as a basis for understanding more specific implementation-
> and application-specific possibilities.
> 
> 2. Specific common solutions.  This should go in the FAQ.  Barry, are
> you maintaining the FAQ?  Would it be possible for you to enumerate some
> of the suggestions posted here?  Topic 2-11 address saving a Lisp image,
> but this could be extended to the other ways of making "an executable". 
> To make it easy, lets presume the existence of a suitable conceptual
> overview at www.lisp.org.
> 
> 3. Specific supported solutions.  This is the province of the vendors.
> 
> 

--Deepak
From: Martin Cracauer
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <7qmbq0$2lhc$1@counter.bik-gmbh.de>
Deepak Goel <·····@Glue.umd.edu> writes:

>what i was wanted to have was: compile my program into one (or 2 or 3)
>file(s) that can then be executed by typing a single command, and that
>such a file, when ftp'ed to a different unix system, would 'run' there as
>well, without the user having to know how to start lisp there on that
>particular unix machine..

>that's what my perception of a 'binary standalone executable' is..
> (or used to be).

>any suggstions u care to make?

Kick the CMUCL developers in the butt to include the `lisp` executable
(startup code) into the dumped Lisp image.

Lispworks does this (IIRC) and I think it's a cool feature. Just ship
the corefile and users can execute it as it was a binary program.

Nowadays, C/C++ applications like WWW browsers are already bigger that
a complete Common Lisp image, so it would be even more desireable than
a few years ago.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar 
 program on a junk operating system, eh?
From: Mike McDonald
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <7qme3e$4gg$1@spitting-spider.aracnet.com>
In article <·············@counter.bik-gmbh.de>,
	········@bik-gmbh.de (Martin Cracauer) writes:

> Kick the CMUCL developers in the butt to include the `lisp` executable
> (startup code) into the dumped Lisp image.

  Well, Martin, you know where the sources are. Have at it! :-) Most of the
"CMUCL developers" have enough trouble just dumping the lisp image, without
having to worry about dumping restartable C code.

> Lispworks does this (IIRC) and I think it's a cool feature. Just ship
> the corefile and users can execute it as it was a binary program.

  Franz, on the other hand, went to the loader/image model with ACL 5.0.

  Mike McDonald
  ·······@mikemac.com
From: Raymond Toy
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <4ng10xkwdz.fsf@rtp.ericsson.se>
>>>>> "Martin" == Martin Cracauer <········@bik-gmbh.de> writes:

    Martin> Kick the CMUCL developers in the butt to include the `lisp` executable
    Martin> (startup code) into the dumped Lisp image.

    Martin> Lispworks does this (IIRC) and I think it's a cool feature. Just ship
    Martin> the corefile and users can execute it as it was a binary program.

So you mean the dumped image actually looks more like the C code with
the dumped image tacked on the end, and the C code know what to do
with the dumped image?

I didn't know that.  That is pretty cool.  And the C code is only a
150K or so, which won't matter in a core file of 15-20 MB.

And, at least for CMUCL, you don't get problems where the lisp image file
and the lisp C code get out of sync, which does happen to me once in a 
while when I do something stupid.

Ray
From: Martin Cracauer
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <7r142l$12o$1@counter.bik-gmbh.de>
Raymond Toy <···@rtp.ericsson.se> writes:

>>>>>> "Martin" == Martin Cracauer <········@bik-gmbh.de> writes:

>    Martin> Kick the CMUCL developers in the butt to include the `lisp` executable
>    Martin> (startup code) into the dumped Lisp image.

>    Martin> Lispworks does this (IIRC) and I think it's a cool feature. Just ship
>    Martin> the corefile and users can execute it as it was a binary program.

>So you mean the dumped image actually looks more like the C code with
>the dumped image tacked on the end, and the C code know what to do
>with the dumped image?

Yes, exactly. I would assume it's pretty easy to do in ELF, but
documentation on hacking object files is rare and nonportable, so
expect some gray hair.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar 
 program on a junk operating system, eh?
From: Eric Marsden
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <wzig10rdmbt.fsf@mail.dotcom.fr>
>>>>> "Martin" == Martin Cracauer <········@bik-gmbh.de> writes:

  Martin> Kick the CMUCL developers in the butt to include the `lisp`
  Martin> executable (startup code) into the dumped Lisp image.

  rt> So you mean the dumped image actually looks more like the C code
  rt> with the dumped image tacked on the end, and the C code know
  rt> what to do with the dumped image?

  Martin> Yes, exactly. I would assume it's pretty easy to do in ELF,
  Martin> but documentation on hacking object files is rare and
  Martin> nonportable, so expect some gray hair.

There is some excellent documentation of object file formats in John
Levine's upcoming book "Linkers and Loaders", whose draft is available
online at 

   <URL:http://www.iecc.com/linker/>

Reading Chapter 3 I notice mention of a .interp section in ELF object
files, which would be interpreted by ld.so to load the interpreter and
any shared libraries (sort of like the #! convention, but extendable to
binary files). Does anyone know whether this is implemented on common
Unices? 
  
-- 
Eric Marsden
It's elephants all the way down
From: Bruno Haible
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <7r2sqq$n2b$1@news.u-bordeaux.fr>
Eric Marsden <········@mail.dotcom.fr> wrote:
>
> Reading Chapter 3 I notice mention of a .interp section in ELF object
> files, which would be interpreted by ld.so to load the interpreter and
> any shared libraries (sort of like the #! convention, but extendable to
> binary files). Does anyone know whether this is implemented on common
> Unices? 

Yes, all ELF based Unices (Solaris, Linux, ...) implement it. This feature
is typically used for executing programs that were compiled for other OSes,
for example the iBCS package which permits to run SVR4 binaries on Linux.
Nowadays it is more used to run Linux binaries on SVR4...

But putting your own value there means that you will have to take care
of not removing the dynamic loading features provided by the "normal"
interpreter (/lib/ld-linux.so.2 on Linux).

              Bruno                           http://clisp.cons.org/
From: Eric Marsden
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <wzi906iet02.fsf@mail.dotcom.fr>
>>>>> "bh" == Bruno Haible <······@clisp.cons.org> writes:

  [.interp section in ELF object files]
  
  bh> Yes, all ELF based Unices (Solaris, Linux, ...) implement it.
  bh> This feature is typically used for executing programs that were
  bh> compiled for other OSes, for example the iBCS package which
  bh> permits to run SVR4 binaries on Linux. Nowadays it is more used
  bh> to run Linux binaries on SVR4...

ok, thanks. For the curious, I investigated a little further. On
GNU/Linux with the GNU binutils:

    ~$ objdump -j .interp --full-contents `which ls` 
    /bin/ls:     file format elf32-i386
     
    Contents of section .interp:
     80480d4 2f6c6962 2f6c642d 6c696e75 782e736f  /lib/ld-linux.so
     80480e4 2e3200                               .2.

On Solaris:

    ~$ /usr/ccs/bin/dump -s -n .interp /bin/ls 
    /bin/ls:     
    .interp:
            2f 75 73 72 2f 6c 69 62 2f 6c 64 2e 73 6f 2e 31 00


  bh> But putting your own value there means that you will have to
  bh> take care of not removing the dynamic loading features provided
  bh> by the "normal" interpreter (/lib/ld-linux.so.2 on Linux).

ok, you'd have to chain in ld.so. But this seems to be an alternative
to the binfmt_misc module on linux[1], which allows you to associate
certain object types with an interpreter.

[1] <URL:http://www.kernelnotes.org/doc22/binfmt_misc.txt>

-- 
Eric Marsden
It's elephants all the way down
From: Barry Margolin
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <lpxx3.469$m84.8465@burlma1-snr2>
In article <·····················@dolphin.openprojects.net>,
Samuel A. Falvo II <······@dolphin.openprojects.net> wrote:
>On Thu, 26 Aug 1999 23:52:24 GMT, Barry Margolin <······@bbnplanet.com> wrote:
>>Huh?  Standalone executables are the norm in Unix?  You type a command name
>>at the shell prompt, the system loads that executable into memory, and runs
>>it.  Why is it so hard to understand writing the program in Lisp to create
>>that executable?
>
>Actually, this is no longer true.  Running ldd on any Unix binary today will
>yield, assuming the executable isn't statically linked (which is a dying
>breed these days anyway) that at least two libraries are referenced by the
>executable, one of which is guaranteed to be a version of libc.

I consider this a standalone executable.  Those libraries are essentially
part of the OS.

Even statically-linked executables aren't truly "standalone", since they
still require the OS kernel.  Standalone is not the same as "unhosted".

I think what the OP probably meant is something that he can distribute to
other users or customers, who may not have a copy of ACL on their system.
People who program in C don't require their end users to have C compilers
on their systems, and Lisp programmers shouldn't require anything special
of their end users' systems, either.  A script that begins by invoking the
Lisp interpreter clearly doesn't fit the bill.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Tim Bradshaw
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <ey34shlrt1f.fsf@lostwithiel.tfeb.org>
* Samuel A Falvo wrote:
> Smalltalk is the quintessential
> example of this thought process, where individual methods are first-class
> objects themselves.

Methods are objects in CL too of course.

> So now we come full circle: is a stand alone application that relies on libc
> (a DLL) really stand-alone?  I, personally, say it's not, since there are
> several other pieces in the "software stack," one of which is libc, and the
> other is the kernel.  libc and the kernel often go hand in hand, so it's
> convenient to treat them as a single entity.  Upon doing this, THEN we see
> that a standalone application under UNIX finally starts to re-appear.
> However, as soon as auxiliary libraries are imported, such as ncurses, GTK,
> etc., suddenly, that fragile distinction is blurred once again.

I think that systems like Unix make quite a large distinction between
stuff above the kernel and stuff inside it, so I think I really
disagree with your bundling of libc and the kernel.  Typically
(always?) the distinction is enforced at the machine level -- a call
into the kernel is not like a normal function call because it involves
changing the state of the CPU in a pretty fundamental way.

What I'm really trying to say is that it seems to me basically a
historical accident that things that use libc are `standalone' while
things that don't are not.  It's just that libc is bundled and liblisp
isn't.  In the context of systems like Windows where there are
hundreds of shared libraries (my win98 box with office and basically
no other applications has 876!) the very concept of `standalone' would
seem to be completely meaningless.  Unix is not far behind either.

--tim
From: Tim Bradshaw
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <ey36721s01t.fsf@lostwithiel.tfeb.org>
* Barry Margolin wrote:

> I think what the OP probably meant is something that he can distribute to
> other users or customers, who may not have a copy of ACL on their system.
> People who program in C don't require their end users to have C compilers
> on their systems, and Lisp programmers shouldn't require anything special
> of their end users' systems, either.  A script that begins by invoking the
> Lisp interpreter clearly doesn't fit the bill.

But they do typically require a whole bunch of shared libraries, and
the presence or absence of such libraries is often a serious
pain. both for the vendor and the user.

I knew people who distributed statically-linked versions of programs
simply because *many* bug reports came down to people not having the
right (or any) motif libraries.

Many Windows machines seem to end up getting totally fouled up by
people installing packages which come with their own, subtly broken,
versions of various crucial DLLs.

OK, shared libraries aren't usually compilers, but I don't see that
that is a vast difference here.  For relatively small and simple
programs, then C does involve less baggage to be shipped with it,
-- it's running on a C-based OS so you'd expect that -- but perl or
java or something needs baggage, and people don't complain too much
about that.

--tim
From: Stig Hemmer
Subject: Re: compiling lisp files into executables..
Date: 
Message-ID: <ekvyaewkm2r.fsf@epoksy.pvv.ntnu.no>
Deepak Goel <·····@Glue.umd.edu> writes:
> how do i create a stand-alone executable file?

What is your real need?
What do you mean by a "stand-alone executable file"?
Why do you think that a SAEF will fill your real need?

Stig Hemmer,
Jack of a Few Trades.