[Gcl-devel] Re: GCL on single board computer

[Camm Maguire]

Greetings!

Andreas Yankopolus <address@hidden> writes:

> Camm,
> 
> Thanks for your response.
> 
> > For lisp applications built on top of GCL on platforms with native
> > object relocation, no GCL files need be installed. This includes ARM
> > and x86.  On platforms using dlopen, GCL itself must be installed
> > only if one wants to compile new system images -- only cmpinclude.h
> > is needed if one wants to compile only lisp object modules, and no
> > files are needed if one does not intend to use the compiler.
> 
> Perhaps I should have asked about the minimal files required to run
> compiled (.o) applications. Some sort of Lisp runtime (apparently
> contained in saved_gcl) seems necessary to for this, since compiling
> and running a Lisp application involves:
> 
> Compile:
> 
> % gcl -compile foo.lisp
> 
> Run:
> 
> % gcl -batch -load foo.o
> 
> Unless I'm missing something, which is likely the case, I haven't seen
> a way to create the equivalent of a statically linked version of
> foo.o. The file saved_gcl appears to serve as a sort of combination
> dynamic loader, linker, and libc for Lisp.
> 

Yes, if you want to just run a .o in batch, you need gcl installed.
You likely don't need both the cltl1 and ansi images, as provided in
the Debian package -- just pick one.  At the minimum, you need the
saved_gcl or saved_ansi_gcl file for this.  All the other files are
either autoloaded when invoking special functionality (e.g. tkl.o), or
are provided to enable compiler::link to rebuild a lisp image from
scratch -- only strictly necessary when 1) wanting to do so and 2) not
on a platform with native object relocation, which is not the case for
you.  

A 'statically linked executable', which is likely what you want, can
be formed by 

gcl
>(load "foo.o")
>(si::save-system "foo")

Then foo is a stand alone executable.

> Cross-compiling on an x86 works great. The conversion of foo.lisp to
> foo.c doesn't appear to depend on the system architecture, and GCL

Will only vary with 32bit/64bit.

> calls arm-linux-gcc to compile foo.c to foo.o without a problem.
> 

Great!  Might ask you about this someday.

> > You might be interested to know that .debs for GCL/arm are available
> > from the Debian repository.  I myself have used these to produce arm
> > .debs for axiom, so I know it can be done.  Tim Daly, the lead axiom
> > developer, wanted to run axiom on his pda at one point.
> 
> I initially didn't think this would work since the machines are
> running the Familiar distribution from handhelds.org. However, the
> .deb installed just fine. Unfortunately, it contains about 14 MB of
> stuff. I'm hoping that I can delete much of that. One option I'm
> considering is compiling GCL myself and passing args to ./configure to
> scale back on features, but it would be easier to just delete unneeded
> files :-)

The tiniest minimal file you need in the .deb is the saved_gcl file,
or a dumped image thereof produced via (si::save-system).  You can
actually save (on x86 at least) another 1 - 1.5 Mb by compiling with
--enable-custreloc --disable-statsysbfd.  We haven not implemented
native relocation code for arm, as its far more portable/scalable for
us to rely on bfd to carry us to the various architectures.  But it
might be worth your while to do so.  You would just need to provide
the reloc information in sfaslelf.c following the examples of x86 and
sparc which are provided.  Please submit this patch if you do so, and
we'll included it.

Take care,


> 
> Thanks,
> 
> Andreas
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah