Cannot build Emacs from source in container-based builds

Question

Cannot build Emacs from source in container-based builds

fmdkdd opened this issue 7 years ago · comments

We provide a Makefile to build different Emacs versions from source in Travis. This is used by several Emacs package developers for their CI. It seems the Trusty update from December 12 prevents Emacs from compiling successfully.

Here is a failed build: https://travis-ci.org/flycheck/flycheck/jobs/328830034
Using the previous Trusty image, the build succeeds: https://travis-ci.org/flycheck/flycheck/builds/328992827

The build fails in the dumping phase:

Dumping under the name emacs
**************************************************
Warning: Your system has a gap between BSS and the
heap (25275672 bytes).  This usually means that exec-shield
or something similar is in effect.  The dump may
fail because of this.  See the section about
exec-shield in etc/PROBLEMS for more information.
**************************************************
/bin/bash: line 7: 10028 Segmentation fault      (core dumped) ./temacs --batch --load loadup bootstrap
make[2]: *** [bootstrap-emacs] Error 1
make[1]: *** [src] Error 2
make: *** [install_emacs] Error 2

Emacs can be a bit tricky to build from source. Here is the relevant section from etc/PROBLEMS:

*** Segfault during 'make'

If Emacs segfaults when 'make' executes one of these commands:

LC_ALL=C ./temacs -batch -l loadup bootstrap
LC_ALL=C ./temacs -batch -l loadup dump

the problem may be due to inadequate workarounds for address space
layout randomization (ASLR), an operating system feature that
randomizes the virtual address space of a process. ASLR is commonly
enabled in Linux and NetBSD kernels, and is intended to deter exploits
of pointer-related bugs in applications. If ASLR is enabled, the
command:

cat /proc/sys/kernel/randomize_va_space # GNU/Linux
sysctl security.pax.aslr.global # NetBSD

outputs a nonzero value.

These segfaults should not occur on most modern systems, because the
Emacs build procedure uses the command 'setfattr' or 'paxctl' to mark
the Emacs executable as requiring non-randomized address space, and
Emacs uses the 'personality' system call to disable address space
randomization when dumping. However, older kernels may not support
'setfattr', 'paxctl', or 'personality', and newer Linux kernels have a
secure computing mode (seccomp) that can be configured to disable the
'personality' call.

It may be possible to work around the 'personality' problem in a newer
Linux kernel by configuring seccomp to allow the 'personality' call.
For example, if you are building Emacs under Docker, you can run the
Docker container with a security profile that allows 'personality' by
using Docker's --security-opt option with an appropriate profile; see
https://docs.docker.com/engine/security/seccomp/.

To work around the ASLR problem in either an older or a newer kernel,
you can temporarily disable the feature while building Emacs. On
GNU/Linux you can do so using the following command (as root).
echo 0 > /proc/sys/kernel/randomize_va_space
You can re-enable the feature when you are done, by echoing the
original value back to the file. NetBSD uses a different command,
e.g., 'sysctl -w security.pax.aslr.global=0'.

Alternatively, you can try using the 'setarch' command when building
temacs like this, where -R disables address space randomization:
setarch $(uname -m) -R make
ASLR is not the only problem that can break Emacs dumping. Another
issue is that in Red Hat Linux kernels, Exec-shield is enabled by
default, and this creates a different memory layout. Emacs should
handle this at build time, but if this fails the following
instructions may be useful. Exec-shield is enabled on your system if
cat /proc/sys/kernel/exec-shield
prints a nonzero value. You can temporarily disable it as follows:
echo 0 > /proc/sys/kernel/exec-shield
As with randomize_va_space, you can re-enable Exec-shield when you are
done, by echoing the original value back to the file.