Summary: | emerge clisp-2.33.2-r1 fails: ./clisp-link: line 550: 20305 Killed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Schreiber <als> |
Component: | [OLD] Development | Assignee: | Gentoo Lisp Project <lisp> |
Status: | RESOLVED FIXED | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexander Schreiber
2005-02-06 15:21:37 UTC
--> glibc-2.3.4.20040808-r1, 2.4.26-grsec i686) I think that you may encounter problems with GRSEC and CLISP/SBCL/CMUCL. If you try the same under a non-GRSEC kernel do you still encounter the same problem? No problems with cmucl or sbcl - both emerged successfully on this same system & environment (did a full system rebuild before after switching from gcc 2.96 to gcc3 - had to remove the formerly working clisp install to get the world rebuild to finish). Both cmucl and sbcl run - as far as a few short tests determined - fine. Unfortunately, I can't test emerging clisp under a non-grsec kernel since this is a production system in a remote location where just rebooting and switching kernels around is not an option. My Gentoo testsystem (where I could try this) is currently unavailable due to hardware failure. I did some further testing. Turns out, if I disable _all_ clisp modules in the ebuild (by removing all --with-module ... entries, disabling PostgreSQL-Support, disabling PCRE-Support), then clisp compiles and installs just fine. As soon as I enable one of the modules, emerging clisp dies as shown. Since my Lisp code does not use any of the clisp modules, this is currently a barely acceptable workaround, but I would prefer to have the ebuild work without resorting to this kind of ebuild butchery ;-) (In reply to comment #0) > glibc-2.3.4.20040808-r1, 2.4.26-grsec i686) > ================================================================= > System uname: 2.4.26-grsec i686 Intel(R) Celeron(TM) CPU 1000MHz Hmm... I have the grsec patches, and pax to boot. What I get is this: make[2]: Entering directory `/var/tmp/portage/clisp-2.34-r1/work/clisp-2.34/build/callback/trampoline_r' ./test1 trampoline: cannot make memory executable I happen to know that pax has an option "EMUTRAMP" that has to do with something called a memory trampoline. But it could be grsec too, or even the pie, ssp and hardened patches to gcc. (Yes, I know, I'm paranoid.) I'm thinking your bug might be similar to mine, even though we got different error messages. Is there anyone who sees a connection between these two errors? Update: the current dev-lisp/clisp-2.34-r1 emerges just fine and works. |