[Openmcl-devel] Re: Standalone binaries

Taoufik Dachraoui taoufik.dachraoui at wanadoo.fr
Fri Apr 18 12:00:10 PDT 2003

The size of the code is obviously critical for performance issues, you 
may have many concurrent users running the application.

Initially I rose this issue just because I was used to develop on 
machines configured for development purposes and run/test my 
application on a test/production environment where there is no 
development tools.


On vendredi, avr 18, 2003, at 19:22 Africa/Tunis, Hamilton Link wrote:

> I still don't understand why you or anyone would be particularly 
> concerned about distributing something as a single file; can you 
> clarify why you need to do this?
> I don't remember the last time I saw an application that was a single, 
> self-contained file. (In any case, anything worth it's salt typically 
> comes with image files, default config files, a README or other 
> documentation, a license file, etc. etc. -- even for homework, the 
> last time I did any that the professor expected to be able to run, I 
> still had to include source code with the executable.)
> anyway...
> You do understand that "installing openmcl" is *not* required, right? 
> Installing the application you wish to distribute *is* required 
> (whatever installing means, to me under unix it typically means 
> "unpack a tar file"), and at a minimum (for several lisp systems 
> including OpenMCL) that means two files, the vendor's lisp kernel and 
> your app's heap image.
> If you really, really, *really* want to distribute a single-file 
> program, you might see if you can find a lisp-to-C translator. There 
> are a couple out there, but I don't know how good they are or whether 
> they're even worth the trouble. If you go that route, Heaven help you.
> My advice is learn to use tar and gzip -- everyone, everywhere, has 
> the capacity to unpack such a file and look in the resulting directory 
> for a README.
> h
> On Friday, April 18, 2003, at 11:42 AM, Taoufik Dachraoui wrote:
>> I did not mean to run an executable on all different unix operating 
>> systems. By 'all unix systems' I meant 'all machines running the same 
>> unix operating system'. For example, the executable I create on my 
>> machine (Mac OS X) can run on any other Mac OS X machine (even if 
>> they do not have openmcl installed).
>> Example, in C when you create an executable, you can take the 
>> executable and run it on any other machine (with the same OS) at a 
>> condition that all shared libraries used by the executable exists 
>> (eg. X11).
>> It is my fault, I was not clear in my statements. I hope that someone 
>> understood my concerns.
>> SAVE-APPLICATION creates an image file, then we need to run dppccl 
>> with the image as an argument, so we cannot run the image in another 
>> system that do not have openmcl installed.
>> I may be not precise in my comments and I ask you to bear with me and 
>> be patient, I am trying to learn as much as I can, and I find the 
>> mail group very interesting.
>> regards
>> Taoufik
>> On vendredi, avr 18, 2003, at 18:28 Africa/Tunis, Erann Gat wrote:
>>> On Fri, 18 Apr 2003, Taoufik Dachraoui wrote:
>>>> the JVM is allover the places, not openmcl.
>>> Sorry, can't help you there.  The world is the way it is.
>>>> For this reason I am looking for a way
>>>> to create an executable where all needed stuff is in it (excluding
>>>> functions in standard unix libraries and system calls), so that my 
>>>> lisp
>>>> applications can run on any unix system (I hope)!
>>> First, there is no way to create a binary executable (in any 
>>> language)
>>> that will "run on any unix system."  If you doubt this, try to take 
>>> any
>>> binary from one unix system (like Linux) and run it on a different 
>>> unix
>>> system (like Solaris).
>>> Second, Gary already told you how to create a standalone executable 
>>> using
>>> save-application.  You complained that it was too big, and I 
>>> explained to
>>> you why it had to be that big, and that the "fact" that apparently
>>> self-contained C binaries appear small is really just an illusion.
>>> The only way to achieve what you seem to want is to make openmcl as
>>> ubiquitous as the JVM.  That is a worthy goal, but very difficult to
>>> achieve.  You are probably better off coming up with another plan.
>>> E.
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list