>>>>> "David" == David Kuehling writes: >>>>> "Ken" == Ken Raeburn writes: >> On Jan 2, 2011, at 08:53, David Kuehling wrote: >>> 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. >> Okay, then you are doing something different... I don't know how >> unexelf.c is going to handle a file with no section headers. As best >> I recall, they're not critical for execution, but unexelf.c may be >> making additional assumptions based on how other systems tend to >> operate. Ideally, I think it should be possible to just extent the >> loadable data sections, but that's not how unexelf.c operates. If >> you can bypass 'sstrip' for a package, or just one executable in the >> package (emacsclient should be fine to strip, for example), that >> might fix the problem and allow you to have it dump during >> installation. > The best solution will be to use strip instead of sstrip, and I think > the NanoNote firmware is going to use that very soon (since more > sstrip problems have been cropping up recently). > Going to post how that turns out. Ok here we go. Recompiled with strip instead of sstrip. Now Emacs is killed by the OOM killer when attempting to dump :( emacs -Q --batch --eval \ '(dump-emacs "./demacs" "/usr/bin/emacs")' [..] Loading vc-hooks... Loading ediff-hook... Finding pointers to doc strings... Finding pointers to doc strings...done Killed (the kernel log contains a message about "out of memory: kill process 652...") Now I'm out of ideas. Thanks for the help, cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40