[Ecls-list] ecl 0.5 build issues on OS X/Solaris. plus questions & feature reqs

[Juan Jose Garcia-Ripoll]

[Side note: sorry for all the duplicate messages I am sending lately.
The time I dedicate to read and answer the list is limited and in such a
hurry I always forget to rewrite the "To:" header to point to the ecls
mailing list. I have asked the SourceForge developers to tweak the list
so that they add a Reply-To: that points to ecls-list, but it is their
policy to never do that :( ]

"John B. Thiel" wrote:
> How close is the dynamic loading, on-the-fly compilation on OS X?  Is it
> known how and technically possible to achieve this?  Is anybody working
> on it?

Last time I tried I got messages due to unresolved symbols. The method
for loading shared libraries in Linux/FreeBSD is based on the fact that
these systems allow one to load libraries with unresolved symbols which
are resolved at run time by means of the executable that loaded it.
Windows does not support this hack and as soon as the mechanism for
loading Windows libraries works, the Mac OSX will have this feature too.

> * BUG:   I was getting ranlib errors when running ecl after the install:
> /usr/bin/ld: table of contents for archive: /usr/local/lib/ecl//libecl.a
> is out of date; rerun ranlib(1) (can't load from it)[...]
> I fixed it with :
>         ranlib /usr/local/lib/ecl/lib*.a
> Makefile should do this step before install, right?

It is wierd that one has to do a "ranlib" after *copying* these files,
when the "ranlib" had already been done at build time. I will look at
this.

> * FEATURE:  It would be nice to add support for the readline library.

This requires work. An easy way to achieve it is to build a CLOS class
that overloads the appropiate methods (See #ifdef CLOS in file.d,
print.d and read.d) and which calls readline. Then the standard input
should be replaced with an instance of
this class.
 
> * FEATURE: It would be nice if the getopt also accepted single letter
> args,  (eg. -l for load).
> Also that 'ecl abc.lisp xyz.lisp ...' might do something logical
> (currently it gives 'unknown flag' error)
> Usage: ecl [-dir dir] [-load file] [-eval expr]
>          [-compile file [-o ofile] [-c [cfile]] [-h [hfile]] [-data
> [datafile]] [-s]]

This can be easily fixed. I will do it if no one does it, but the code
is just lisp and it appears in src/lsp/top.lsp
 
> * QUESTION: Is it supported to link .o files or libraries compiled from
> original .c files, and call them from ECL?  If so, how? I did not find
> this case in the documentation which seems more oriented to the model of
> embedding C bodies, or calling lisp code from C.  For example, I tried
> to build an image with
>         fac.o compiled from fac.c via gcc, and
>         fib.o compiled from fib.lsp via ecl -s ,  and
>         ff.o from ff.lsp containing
>                 (defentry fac (int) (int fac))
> 
> The build step failed with:
> ecl -eval '(c::build-program "ecl-fib" :lisp-files (quote ("ff.o"
> "fib.o" "fac.o")))'

The mistake is that fac.o is not a "lisp file", but rather an extra
argument to the linker "ld". Therefore the right way would be to pass
"fac.o" in :ld-flags.

(c::build-program "ecl-fib" :lisp-files '("ff.o" "fib.o") :ld-flags
'("fac.o"))

That should work (I haven't checked it, though :).

> =========================
> SOLARIS 8  (Blade 100)
> BUG: Build is failing

Solaris is not supported yet. I am working on that, but problems with
the garbage collectors (both of them) are in the way.

Juanjo