Re: Some OpenWrt port related problems

[David Kuehling <dvdkhlng@gmx.de>]

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

>>>>> "Ken" == Ken Raeburn <raeburn@raeburn.org> writes:

> On Jan 2, 2011, at 08:53, David Kuehling wrote:
>> 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.

> Eh.. I've never been convinced that it's a good thing.  I like the
> fact that mmap/malloc can fail, and give you a chance to recover,
> rather than simply having a process blown out of the water when it
> turns out that a page isn't actually available after all.  But that's
> just me....

Yes don't like it too much either, just a workaround as nobody is going
to fix the mmap() in the near future :)  Plus I just witnessed GNU Octave
use 64MB of virtual memory on the 32MB RAM nanonote, so over-allocating
memomory seems to be a common disease nowadays.

>> $ 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.

> 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.

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 --]