[cl-debian] Bug#487435: gcl sbrk patch

Greetings, and thank you so much for this *very* helpful work! I've modified very slightly in the newly uploaded -38 -- please let me know if this works for you. (Some machines pass the personality resetting step, but still fail to pass this personality to the re-execed subprocess :-)) I block loops with an environment variable. Felt a little nervous about the portability of readlink. Would love to autogenerate configure -- not yet. Take care, Peter De Wachter <pdewacht@gmail.com> writes:
Package: gcl Version: 2.6.7-36.1 Followup-For: Bug #487435
The attached patch fixes gcl's personality(ADDR_NO_RANDOMIZE) code. (BTW, this randomization seems to have become enabled by default Debian's 2.6.25 amd64 kernels).
- gcl tries to figure out at build time whether the randomized sbrk work-around is needed. But such things should be either checked at run-time or applied unconditionally. (The buildd could still be running an old kernel, or the user might have a paranoid setup, etc.) So I patched the configure.in script. The new logic is:
- check if ADDR_NO_RANDOMIZE is defined in the system headers. If not, define it ourselves. [This was the cause of this FTBS, gcl #defined it unconditionally, while glibc now has it as an enum value.]
- check if personality(ADDR_NO_RANDOMIZE) compiles and is accepted by the kernel.
- if it works, use it unconditionally.
- if it does not work, check if address randomization is in effect. Refuse to build if it is.
Currently, debian/rules does not try to regenerate configure, referering the some bug with autoconf and emacsen-common. I'll leave that part to you :)
- I replaced the code in o/main.c with the equivalent code from sbcl, which seems more robust (it protects against an infinite loop on broken kernels, and doesn't rely on the value of argv[0]).
(Also, both the configure script and main.c tried to use personality(-1) to get the current personality. This fails on 64-bit systems, the correct call is personality(0xffffffffUL)).
- When compiling with profiling, I added a call to gprof_cleanup() before exec'ing, otherwise the build would fail with SIGPROF.
All programs requiring gcl should probably be rebuild when this is fixed.
-- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64)
Kernel: Linux 2.6.25-2-amd64 (SMP w/1 CPU core) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Versions of packages gcl depends on: ii debconf 1.5.22 Debian configuration management sy ii emacs [emacsen] 22.2+2-2 The GNU Emacs editor (metapackage) ii emacs22-gtk [emacsen] 22.2+2-2 The GNU Emacs editor (with GTK use ii gcc 4:4.3.1-2 The GNU C compiler ii libc6 2.7-12 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libncurses5 5.6+20080713-1 shared libraries for terminal hand ii libreadline5 5.2-3 GNU readline and history libraries ii libsm6 2:1.0.3-2 X11 Session Management library ii libx11-6 2:1.1.4-2 X11 client-side library ii libxaw7 2:1.0.4-2 X11 Athena Widget library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii tcl8.4 8.4.19-2 Tcl (the Tool Command Language) v8 ii tk8.4 8.4.19-2 Tk toolkit for Tcl and X11, v8.4 -
gcl recommends no packages.
Versions of packages gcl suggests: pn gcl-doc <none> (no description available)
-- debconf information: gcl/default_gcl_ansi: gcl/default_gcl_prof:
-- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
participants (1)
-
Camm Maguire