Summary: | dev-lisp/gcl-2.6.7 doesn't compile in hardened gentoo amd64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pedro Monteiro <pedro.mont> |
Component: | Current packages | Assignee: | Common Lisp Bugs <common-lisp> |
Status: | RESOLVED DUPLICATE | ||
Severity: | major | CC: | hardened, pedro.mont |
Priority: | High | ||
Version: | 2005.1 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Pedro Monteiro
2006-01-18 05:18:56 UTC
It seems "hardened" linux environments do not work with SBCL, CMUCL, CLISP, GCL etc. and perhaps many other image-based language implementations. I will probably fix this bug the same way I fixed a similar bug for SBCL, and that is to detect hardened features in pkg_setup() and issue an error when found. eg. pkg_setup() { if use hardened && gcc-config -c |grep -qv vanilla; then while read line; do einfo "${line}"; done <<'EOF' So-called "hardened" compiler features are incompatible with SBCL. You must use gcc-config to select a profile with non-hardened features (the "vanilla" profile) and "source /etc/profile" before continuing. EOF die So as a work around, you can switch GCC profiles to a non-hardened one (with the gcc-config command). This is wrong way to do it of course. Adding hardened@gentoo.org, adding to CC. Hmm; you already have 'filter-flags -fPIC' - however I suggest you use filter-flags -fPIE as filter-flags -fPIC may have unintended consequences if CFLAGS includes -fPIC. Having said that, CFLAGS shouldn't ever include -fPIC, althoug things may be different on amd64. Beyond that, things get more complicated for a hardened (PaX) kernel. gcl relies on brk/sbrk returning heap immediately following the text segment, which ideally it wouldn't do. Emacs used to suffer from this. Eliminating this assumption in the code is quite a big job, however - gcl includes its own version of libiberty, and does its heap allocation manually. The alternative is to relax the restriction for gcl - this means removing the check in configure, and PaX-marking executables 'r' (see bug #154887 for the sort of thing that may be required). GCL itself already sorts things out with Execshield systems by making a syscall to switch off the randomisation - something not provided by PaX since in PaX the relaxation of the various restrictions is controlled solely by the kernel, whereas in ExecShield relaxation can be controlled from userland. *** This bug has been marked as a duplicate of bug 132873 *** |