severity 572538 important thanks Greetings, and thank you for your detailed feedback. This does appear quite kernel/platform specific, as the default /sbin/sysctl vm.mmap_min_addr on my system is 0, (default kernel, i386), and of course I cannot reproduce your problem. My guess is that this is also the the default, (or the also working 65536, which probably means "any") on the autobuilder which contructed your package.
The gcl binary is saved via unexec from an executing state on a machine which successfully built the package (same as emacs). My guess also is that if you built from source, you would likely get a working image dump. gclcvs attempts to detect whether it can get more heap room by lowering its start address at configure time. If this works, a linker script is constructed (/usr/lib/gcl-2.7.0/unixport/gcl.script) with the correct instructions, and perhaps 128Mb extra heap is available. I think you have found a situation in which such an "optimized" binary is not portable across multiple kernel configurations. This is not new. gcl must also work around sbrk randomization by the kernel, which it attempts to do automatically at runtime. It tests segfault address recovery at first run of (si::sgc-on), and disables the facility if broken on the running machine. Certain arm machines allowed certain assembly instructions that others simply ignored. Finally, if some kernel security package prohibits execution from the .data section, gcl will also bail. I think that this is best addressed by a trap statement in the wrapper script pointing to possible kernel settings needing adjustment. Perhaps an external webpage with updated info as time goes on. Do you agree? Take care, -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
