On Tue, Aug 18, 2009 at 6:09 AM, Juan Jose Garcia-Ripoll <span dir="ltr"><<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Aug 17, 2009 at 2:08 AM, Elliott<br>
<div class="im">Slaughter<<a href="mailto:elliottslaughter@gmail.com">elliottslaughter@gmail.com</a>> wrote:<br>
</div><div class="im">> I am using the Maemo SDK+ 1.0.0 [1] from Nokia. The SDK includes the cross<br>
> compiler [2], the emulator (qemu), etc, the versions of which are all<br>
> determined by the rootstrap (I'm using the last version for diablo [3]).<br>
</div>> Hope this helps.<br>
<br>
I have been working for two days with the maemo-sdk v4.1.<br>
<br>
For some reason the garbage collector fails to work on it. Trying a<br>
newer version of the garbage collector also does not seem to help. But<br>
as I said, it is a problem with the Boehm-Weiser garbage collection<br>
library: it generates SIGSEGV signals without apparent reason.<br>
<br>
Unfortunately the maemo environment is deficient enough that debugging<br>
is not possible (I had to use printfs everywhere to find the problem)<br>
and it is currently out of my reach to find out the actual problem<br>
with that library.<br>
<br>
>From what I can say, this is not arm-specific, for the same library<br>
works in other ARM emulator images, with probably newer versions of<br>
qemu -- it is difficult for me to find out the version used by<br>
scratchbox here, but it seems to be lacking a lot of system calls.<br></blockquote></div><br>I have been trying CPU transparency mode (<a href="http://maemo-sdk.garage.maemo.org/cpu-transparency-guide.html">http://maemo-sdk.garage.maemo.org/cpu-transparency-guide.html</a>), which gets me significantly further in the build process. (Basically, it set up an sshd process on the device and copy binaries files over so they can run natively instead of emulating them.)<br clear="all">
<br>When running natively, I can load the minimal lisp image and start compiling... Unfortunately, the process is a bit finicky and I keep getting errors like the following if I let the device sleep too long.<br><br>;;; Internal error: Read or write operation to stream #<output stream #P"build:lsp;predlib.h.NEWEST"> signaled an error.<br>
;;; Explanation: Transport endpoint is not connected.<br>;;; Internal error: Cannot close stream #<output stream #P"build:lsp;predlib.h.NEWEST">.<br>;;; Explanation: Transport endpoint is not connected.<br>
;;; Internal error: Read or write operation to stream #<output stream #P"build:lsp;predlib.c.NEWEST"> signaled an error.<br>;;; Explanation: Transport endpoint is not connected.<br>(compile-file "src:lsp;seq.lsp" :output-file #P"build:lsp;seq.o.NEWEST" :SYSTEM-P T :C-FILE T :DATA-FILE T :H-FILE T)<br>
<br>Filesystem error with pathname "src:lsp;seq.lsp".<br>Either<br> 1) the file does not exist, or<br> 2) we are not allow to access the file, or<br> 3) the pathname points to a broken symbolic link.<br><br><br>
-- <br>Elliott Slaughter<br><br>"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay<br>