[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Version 1993-11-08 under Linux
- To: firstname.lastname@example.org (Bruno Haible)
- Subject: Re: Version 1993-11-08 under Linux
- From: email@example.com
- Date: Sun, 21 Nov 1993 19:57:27 -0500 (EST)
- Cc: firstname.lastname@example.org (CLISP mailing list)
- In-reply-to: <9311220031.AA02429@ma2s2.mathematik.uni-karlsruhe.de> from "Bruno Haible" at Nov 22, 93 01:31:15 am
> > in unixconf.h, SHMAT_CONST should be defined to nothing.
> Oops. I should have noticed this. What does the declaration of shmat()
> look like in your /usr/include/sys/shm.h ?
extern char *shmat __P((int __shmid, char *__shmaddr, int __shmflg));
> I had the same problem some weeks ago, and I thought it was a problem in gcc.
> I sent a bug report to the gcc people, and Stallman patched gcc. The problem
> was that gcc must not treat "setjmp" like any other C function, but on Linux
> with a new libc setjmp is really called __setjmp - and gcc didn't know about
Hmm. Is it that setjmp() should be declared __attribute__ ((noreturn)),
or something other that gcc needs to know?
> > I will investigate further. I'm installing gcc 2.5.4 tonight.
> Recall that gcc-2.5 requires inc-4.4.4b or newer.
Hmm. I compiled gcc 2.5.4 myself with library 4.4.4 (non-beta). Maybe
I should upgrade my libc and include files.
I found a couple of new problems; the first is that kernel 0.99.13 ALPHAr
(and a few earlier releases, too) have changed kmalloc() so that it can
allocate a maximum of 4072 bytes or so. THe upshot of that is that
SHMMAX needs to be reduced because fewer page pointers can fit on one
kmalloc()ed page. I think I used 0x3fa000.
Another problem was that I couldn't compile maxima. It compiled all
the files fine, then started loading, got to mopers.fas, and sat
there spinning. I left it for a couple of hours with no results.
Then I did an strace on it, and it was continually readdir()ing
the root directory and /bin! Do you have any idea what this is
And starting clisp with 4 megs of memory caused it to eventually
fail with "No room for Lisp Objects" when attempting to compile
maxima. This could just be a side-effect of the above problem.
If I send sigquit to clisp, it doesn't get to remove the main
shared memory segment(s). Though they are attached 42 times, they
aren't destroyed. Could they be deleted so that when clisp
terminates they are automaticaly disposed of?