Re: Some OpenWrt port related problems

[David Kuehling <dvdkhlng@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

>>>>> "David" == David Kuehling <dvdkhlng@gmx.de> writes:

>>>>> "Ken" == Ken Raeburn <raeburn@raeburn.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]