From: ken yip
Subject: compatibility of binary images
Date: 
Message-ID: <1992May18.184136.11697@cs.yale.edu>
A program compiled by say Allegro wouldn't run under Lucid or Harlequin
even for the same machine.   What are the reasons?  What is the correct
way to distribute binary images then?
From: Barry Margolin
Subject: Re: compatibility of binary images
Date: 
Message-ID: <v93m9INNrv9@early-bird.think.com>
In article <······················@cs.yale.edu> ·······@CS.YALE.EDU (ken yip) writes:
>A program compiled by say Allegro wouldn't run under Lucid or Harlequin
>even for the same machine.   What are the reasons?

Lisp compiled functions generally contain many references to routines in
the runtime library of the Lisp implementation that created them.  These
references are generally linked dynamically when the file is loaded into
the Lisp image.  There is no standardization among vendors regarding these
internal routines.  This level of compatibility is extremely difficult to
achieve, due to the size of Common Lisp and the many different optimization
possibilities.  For instance, some implementations will recognize calls to
sequence functions with particular combinations of options and generate
calls to specialized versions of the function; for such binaries to be
compatible across implementations, they must all implement the same
specialized functions.

>  What is the correct
>way to distribute binary images then?

I don't think you mean "binary images"; I interpret that to mean the saved
process images (e.g. what Lucid's DISKSAVE function creates).  The file
that COMPILE-FILE creates is usually called a "compiled file", "object
file", or "bin file" (old-timers call it a "FASL file").

Binary images generally are self-contained, and include the entire Lisp
implementation in addition to the applications that have been loaded.

Bin files, though, are designed to be loaded into a Lisp image.  In general,
you either make binaries for different Lisp implementations available, or
you require the customer to be running the implementation of Lisp you
compiled for.

One possibility would be to use something like Ibuki's CONS compiler, which
converts a set of Lisp functions into a C-callable library.  You could then
load this library into each Lisp using its foreign function interface.
When you distribute the library you'd also have to distribute CONS's
runtime library; I don't know what the licensing issues are there.  This
could get very weird!

Given the large runtime library provided by Lisp, you can think of it as an
OS extension.  An analogy would be that a program compiled for an 80386
running Unix won't run on an 80386 running DOS, and maybe not even on an
80286 running a different Unix implementation.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

······@think.com          {uunet,harvard}!think!barmar