Seeing sbcl/maxima-related build issues on ppc (again): http://buildsys.fedoraproject.org/logs/fedora-development-extras/32693-maxima-5.11.99-0.1.rc2.fc7/ build.log: ... ; - Loading source file ; "/builddir/build/BUILD/maxima-5.11.99rc2/src/init-cl.lisp" ; loading #P"/builddir/build/BUILD/maxima-5.11.99rc2/src/init-cl.lisp" ; in: LAMBDA NIL ; (FIRST MAXIMA::DEV) ; --> CAR ; ==> ; MAXIMA::DEV ; ; note: deleting unreachable code ; - Providing system maxima ; ; compilation unit finished ; printed 1 note [doing purification: roots handlers stack bindings static cleanup**** Whoa! allocation trap and we weren't in lisp! Control stack guard page temporarily disabled: proceed with caution debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED: Control stack exhausted (no more space for function call frames). This is probably due to heavily nested or infinitely recursive function calls, or a tail call that SBCL cannot or has not optimized away. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. Cc'ing Juho who helped out last time (feel free to remove yourself if not interested).
hm, my local mirror doesn't have sbcl-1.0.5 yet.
Just built sbcl-1.0.5, http://buildsys.fedoraproject.org/logs/fedora-development-extras/32690-sbcl-1.0.5-1.fc7/ may be interesting to see if you can get it to build with sbcl-1.0.4 too.
Juho, I've given you an account on bombadil.infradead.org, which runs Fedora rawhide. Note that we've reverted to 4KiB pages on the PPC64 kernel again; that shouldn't be an issue.
FWIW I see the same error when I build against 1.0.4.
Thanks for the account David. I think it doesn't have a authorized_keys (or there's some other problem with the ssh setup), since I'm queried for a password on bombadil.infradead.org but not on power5.infradead.org. It does indeed look as if purification of the core has been broken on ppc somewhere between 1.0 and 1.0.4. Presumably because ppc is using the generational GC these days, and purification is normally only used with the Cheney GC. It looks as if the Maxima build scripts are overriding the default behaviour by passing :purify t to save-lisp-and-die. This is generally a bad idea, and will result in worse performance on x86 and x86-64 than if :purify had been left unspecified. So removing that parameter from the Maxima build would be the right thing, and should have the added benefit of not triggering this bug. I'll check whether there's some obvious change that would've caused the breakage, but we'll probably fix this in 1.0.6 by making purification a no-op when compiling with the generational GC. That's been the plan all along, there's just never been any compelling reason to do it now rather than next month.
Oops, I screwed up cutting and pasting your key. Should work now. I'd forgotten I'd given you an account on power5 -- and any other machine I'd given you an account on has probably been reinstalled a dozen times since then :)
re: comment #5 Thanks for the tip, I'll try 's|:purify t|:purify|'
That should rather be s/:purify t//.
That did the trick, thanks again Juho. %changelog * Sun Apr 29 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 5.11.99-0.3.rc2 - fix sbcl/ppc build (#238376)