[Ecls-list] calling ECL functions defined in an ASDF package from C code

[Juan Jose Garcia-Ripoll]

On Thu, Jul 14, 2011 at 10:59 PM, Ph. Marek <philipp at marek.priv.at> wrote:

> I've tried that ... but:
>
>  * I would always get the error about
>      (setf c::*compile-in-constants* t)
>    I did patch my ECL to get rid of that.
>   Where should I set that? I had it in the .asd file, in my .eclrc,
>   and a few source files ...
>
>  * After compilation I get an executable. But starting it results in
>   "There exists no package with name "USOCKET-SYSTEM"".
>   I thought that (asdf:make-build) would track all dependencies?
>   Is that not so?
>

I just noticed this unfinished thread, sorry. I have checked some examples
and here is the answer.

* The problem with *compile-in-constants* is that ECL has two ways of
building binary files. One is constrained to a certain size of data, the
other one is not, and it is the default, but does not allow building
executables or shared libraries. So if you want to use ASDF:MAKE-BUILD you
should add the line
    (require :cmp)
    (setf c::*compile-in-constants* t)
to ~/.eclrc way before you load quicklisp.

* Regarding the second, the USOCKET library is broken for the type of use
you intend. It is so for various reasons (see also
http://tream.dreamhosters.com/tream/musings/49-lisp/76-analysis-of-existing-asdf-files
)
   - It has imperative statements in the *.asd file which the system depends
on
   - It expects ASDF to exist when loaded, but it does so only to define a
pathname translation which is not used
   - In *.asd it defines a package usocket-system which is actually not
needed because ASDF creates a package for it.
You will find this problem with a variety of libraries that are misdesigned
and do not expect the possibility of being distributed independently of ASDF
and of LOAD.

I attach a fix for usockets in a separate email.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110826/1ba26fd0/attachment.html>