Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
If you try to compile SBCL on Linux systems with a hardened toolchain,
which is starting to be an option on many distros nowadays, you run
into the following error (irrelevant warnings have been silently
gcc -g -Wall -O3 -DSBCL_HOME='"/usr/lib/sbcl"' -I. -c -o linux-os.o
linux-os.c: In function `sys_futex':
linux-os.c:64: error: can't find a register in class `BREG' while
An identical error occurs later, in linux-os.c, if the :sb-futex
feature isn't included.
An explanation of what's going on is here:
The short version is that 'hardened' compilers compile all their code
as position-independent, which will bork the _syscall macros in
x86-linux-os.c (if using the :sb-futex feature) and linux-os.c.
Also, kernel hackers fiat that the _syscall macros should never be used
in userspace, period:
I've attached a patch which does not fix the problem. It does fix the
compile error by using syscall(2) instead of the kernel _syscall
macros, in the same way that other applications which have dealt with
this problem have fixed it. However, when sbcl actually tries to
launch, it dies and falls into the LDB.
For all that I know, this might be because the compiled code is
position-independent rather than having anything to do with the syscall
fix; I know very little about SBCL internals. Since the INSTALL
document specifically mentions that Fedora's exec-shield causes these
problems, and both exec-shield and the hardened toolchain will prevent
Emacs from compiling correctly. If that is true, then my patch may be
correct after all.
Most systems which support the hardened toolchain have a way of
disabling it, typically by passing the options `-fno-stack-protector
-fno-stack-protector-all -nopie' to GCC, or enabling some option that
does that for you.
If SBCL /does/ need these options to be set to off to avoid generating
PIC code, it would be nice if they could be added in or otherwise
enabled somehow. Since the error doesn't mention PIC code or give any
indication that the problem involves it, it was a bit of an adventure
to figure out what exactly was breaking.