I downloaded 18e[1], but it only results in a segementation fault (no
other error messages) when I try to run it on my Slackware 7.2.0
system with the 2.2.19 kernel.
: filestore tmp; file /usr/local/bin/lisp
/usr/local/bin/lisp: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped
: filestore tmp; ldd /usr/local/bin/lisp
libdl.so.2 => /lib/libdl.so.2 (0x2aac7000)
libm.so.6 => /lib/libm.so.6 (0x2aaca000)
libc.so.6 => /lib/libc.so.6 (0x2aae8000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaab000)
: filestore tmp; /usr/local/bin/lisp
The last thing I see when I run strace is
: filestore tmp; strace /usr/local/bin/lisp
...
...
...
old_mmap(0x28000000, 268431360, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x28000000
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
Is this a known problem? Are there any other binary CMUCL
distributions out there which will run on Slackware 7.2.0? Where can I
find the most up to date build procedure for CMUCL?
Petter
[1]
ftp://cmucl.cons.org/pub/lisp/cmucl/binaries/cmucl-18e-pre1-x86-linux.tar.bz2
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
>>>>> "pg" == Petter Gustad <·············@gustad.com> writes:
pg> I downloaded 18e[1], but it only results in a segementation fault (no
pg> other error messages) when I try to run it on my Slackware 7.2.0
pg> system with the 2.2.19 kernel.
pg> ftp://cmucl.cons.org/pub/lisp/cmucl/binaries/cmucl-18e-pre1-x86-linux.tar.bz2
you didn't download CMUCL 18e; you downloaded one of the pretest
binaries. The release binaries are in a directory named release/18e
on the download sites.
pg> Is this a known problem? Are there any other binary CMUCL
pg> distributions out there which will run on Slackware 7.2.0?
two situations that I know of that have led to this behaviour are:
- certain configurations of HIGHMEM support in the kernel change
the memory map available to applications in a way that interferes
with the (somewhat static) assumptions made by CMUCL.
- some security-related mechanisms such as the grsecurity kernel
patches (their all-the-world-is-C assumption doesn't hold for
CMUCL) or libsafe, whose system call interposition mechanism
seems to mess up CMUCL's FFI.
I suggest you try with a "vanilla" kernel to see whether that resolves
your problem. If you can't change your kernel, you will need to
rebuild CMUCL with a changed memory map, which requires a
cross-compile.
pg> Where can I find the most up to date build procedure for CMUCL?
the build scripts are now distributed with the CMUCL sources, in the
src/tools directory. There is a README to get you started. Note that
building CMUCL isn't a trivial exercise.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>