Michael Meskes wrote: > I absolutely agree. In the meantime I have been able to reproduce the problem, > it tries malloc'ing an amazingly high number of memory.
Looking at the build-log <http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=gforth-build-log;att=1;bug=484222>, I see that first the image-generating step fails: |GFORTHD="./gforth-ditc -p .:." GFORTH="./gforth-ditc --die-on-signal -p .:. -i kernl64l.fi -e 3 exboot.fs startup.fs " ./gforthmi gforth.fi --die-on-signal -p ".:~+:." -i kernl64l.fi -e 3 exboot.fs startup.fs | |in file included from *the terminal*:0 |*evaluated string*:-1: images produced by different engines This is probably because of address-space randomization; gforth-0.7.0 is able to build on systems with address-space randomization; it may be a good idea to have a 0.7.0 package for Debian, but a patch for 0.6.2 is at <http://www.complang.tuwien.ac.at/forth/gforth/Known-problems.html#exec-shield> Despite this failure, the build continues, and later tries to use the image (gforth.fi) in the step that fails; apparently it does find a gforth.fi that's corrupt (incomplete?), gets the wrong size info (maybe from uninitialized memory), and finally fails for good. - anton -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
