>>>>> "Ken" == Ken Raeburn writes: > On Jan 1, 2011, at 10:34, Eli Zaretskii wrote: >>> From: David Kuehling Date: Sat, 01 Jan 2011 >>> 15:20:58 +0100 Cc: rms@gnu.org, Emacs Dev >>> Finding pointers to doc strings...done emacs: Can't allocate buffer >>> for /usr/bin/emacs >>> >>> So it wants to pull a full copy of the emacs binary into memory? >> >> It tries to mmap it, yes: > Contrary to the comment in unexelf.c saying "We do not use mmap > because that fails with NFS." :-) > Perhaps we could reduce the memory requirement a bit by (in the ELF > case) mapping the ELF header and read-only sections as shared, > read-only data, so the process wouldn't need space from the OS for > private modifications to those pages. Well, if those pages are not modified, no memory is needed from the OS anyway (i.e. copy-on-write/lazy copy). Just that linux VM manager seems to usually check whether it has enough pages just-in-case. Similar problems seem to crop up with fork();exec() inside emacs. So enabling overcommitting on the NanoNote may be a good thing in general. [..] > I did a MIPS32 (Lemote laptop) GNU/Linux build of the latest alpha > snapshot; no error was produced. According to "readelf -e", temacs > has no .sbss section. The on-disk part of segment 4 does end at the > start of BSS, and it's the segment with the highest memory address > (not file offset) overall, so there's nothing mapped higher than the > BSS. So I'm afraid I can't help much, at least without more info > (e.g., "readelf -e temacs", to see how it's different from mine). And > I'm not sure I know enough about the linker view on MIPS to help > anyways. $ readelf -t /usr/bin/emacs There are no sections in this file. :) Could it be that 'sstrip' (that's no typo, it's not vanilla 'strip') used for openwrt packages causes collateral damage here? Emacs won't be the only package effected. David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40