Package dev-lisp/gcl-2.6.7 doesn't compile in hardened gentoo amd64. Some details about the system: CFLAGS="-O2" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="${CFLAGS}" USE="ansi hardened pic -X -gnome -gtk -gtk2 -kde" Profile is default-linux/amd64/2005.1. Error is: -------------------------------------------------------------------------- gcc -o raw_pre_gcl -L. -Wl,-Map raw_pre_gcl_map -lpre_gcl -lm -lgmp -lreadline -lncurses -lc -lgclp /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: ./libpre_gcl.a(main.o): relocation R_X86_64_32 against `segmentation_catcher' can not be used when making a shared object; recompile with -fPIC ./libpre_gcl.a: could not read symbols: Bad value collect2: ld returned 1 exit status -------------------------------------------------------------------------- Using gcc (GCC) 3.4.4 (Gentoo Hardened 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
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 ***
