Problems installing CMUCL and missing packages in gcl

[vi...@yoyo.cc.monash.edu.au]

I downloaded the executables for sunOs5.3 which it says should work on solaris
5.x system. Well, we're running 5.5 and whenever I try to run lisp, it gives
the error:

segv_handler: No mapping fault: 0x00978000
segv_handler: Recursive no mapping fault (stack overflow?)

Does anyone know what it is and how to fix it?

I've got gcl working fine, but I've got some code from another person that
wrote the code in CMUCL. Most of the code works fine, but they have used a
couple of packages like ext, unix, wire, etc that I can't find in gcl. I'm
assuming they are in CMUCL. I urgently need these packages. If anyone can
help, please e-mail me.

Please e-mail me all replies as well as post them to the newsserver.

Thanks
Vivek

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

[Erik Naggum]

* vi...@yoyo.cc.monash.edu.au

| Does anyone know what it is and how to fix it?

/tmp/ is a tmpfs, a "RAMdisk", coexisting with swap space. there's some
environment variable you can tweak to make CMUCL try elsewhere. call
`strings' on the CMUCL image and grep for "TMP". it'll be obvious.

| Please e-mail me all replies as well as post them to the newsserver.

done.

#:Erik

[Raymond Toy]

>>>>> "vivek" == vivek <vi...@yoyo.cc.monash.edu.au> writes:

vivek> I downloaded the executables for sunOs5.3 which it says should work on solaris
vivek> 5.x system. Well, we're running 5.5 and whenever I try to run lisp, it gives
vivek> the error:

vivek> segv_handler: No mapping fault: 0x00978000
vivek> segv_handler: Recursive no mapping fault (stack overflow?)

vivek> Does anyone know what it is and how to fix it?

Try getting a more update version from www.cons.org. I believe the
versions there will run on any Sparc with Solaris 2.4 and up.

Ray

[Tim Bradshaw]

* Erik Naggum wrote:
> /tmp/ is a tmpfs, a "RAMdisk", coexisting with swap space. there's some
> environment variable you can tweak to make CMUCL try elsewhere. call
> `strings' on the CMUCL image and grep for "TMP". it'll be obvious.

I think the variable you want is CMUCL_EMPTYFILE which should point at
something which is on a real UFS filesystem. /var/tmp/<something> is
OK on Solaris. This is all something to do with mmap(2) being funny
about mapping non-UFS files (I think).

(posted because I'm not sure that grepping for TMP will work)

--tim