Re: core dump while building 1997-09-25 on NetBSD-i386

[Sean Doran <smd@ebone.net>]

Bruno Haible <haible@ilog.fr> writes:

> This looks like a problem with generational GC. (I thought NetBSD's
> support of mmap, mprotect etc. was functional now.) Try adding
> -DNO_GENERATIONAL_GC to the CFLAGS, rm *.o and recompile. If that
> doesn't help, try it first with -DSAFETY=3, then with -DSAFEFY=2,
> and so on until -DSAFETY=0.

None of this worked.

However, I have compiled successfully using

CFLAGS = -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit \
-Wreturn-type -fomit-frame-pointer -O2 \
-fexpensive-optimizations -DDYNAMIC_FFI -DNO_READLINE \
-DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE -DNO_SINGLEMAP \
-DNO_TRIVIALMAP

With the last two lines being the additional options I
supplied after the makemake.

make went without a hitch other than dealing with the
shell bug you mentioned.

make test (NetBSD 1.2G current, P54C (i586/166) gcc 2.7.2.2):

Test passed.
      103.99 real        85.07 user         3.73 sys

I guess based on the PLATFORMS file that this is
half-decent performance.  :-)

make testsuite passed OK too.

I guess this means the absence of wide isn't going to bite me?
Also, does the absence of -DNO_GENERATIONAL_GC even in the 
presence of the lack of shared memory stuff mean that the
generational GC is installed?  (how do i tell?)

Finally, do you think it's worth building again with some
of the -DNO... things removed to see which one is
triggering the problem?

	Sean.

P.S.: I'm also very happy that the reason I started
      looking at CLISP in the first place seems to work
with the new binary (CMUCL was nice and fast but the
Python compiler has problems with tail recursion and lazy
lists which keeps a reference to the head of an infinite
lazy list; I started using CMUCL because scheme48/scsh
simply was too slow to tolerate for a particular
application I'm working on).