[Openmcl-devel] Re: Standalone binaries
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
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.)
> 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.
> 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.
>> 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
>>>> applications can run on any unix system (I hope)!
>>> First, there is no way to create a binary executable (in any
>>> that will "run on any unix system." If you doubt this, try to take
>>> binary from one unix system (like Linux) and run it on a different
>>> system (like Solaris).
>>> Second, Gary already told you how to create a standalone executable
>>> 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.
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
More information about the Openmcl-devel