>>>>> "Delbert" == Delbert Franz <d...@sonic.net> writes:

> I have spent some more time (way too much) on sorting out why it is
> not possible to create a shared library or executable on the Ben using
> the native GCC and related tools.  I reported this on 20 December so
> this is an update to my E-mail on that date:

> 1.  The first problem is the build uses sstrip, or super strip, to
> remove unneeded information from shared libraries.  The libraries
> still work for loading with a shared executable but they will not work
> for compiling a new one.  Thus I changed the option to do no stripping
> and rebuilt my images.  I have also used strip and that is okay and
> does reduce the sizes of the shared libraries.  One can still compile
> and link natively though.

I'm continuously stumbling into problems with sstrip'ed binaries, too.
Gforth's libffi C-interface won't work with a sstrip'ed gforth binary.
Also Emacs' dumping support (i.e. quick startup from compiled image) is
broken, and sstrip looks like the culprit.

I just saw that 'make menuconfig' allows one to configure the stripping
method and change 'sstrip' for 'strip'.  So if it's oficially supported,
what's keeping us from using it?

AFAICS the only rationale for 'sstrip' is for keeping flash memory usage
down.  With 2GB of flash available on the NanoNote, maybe we shouldn't
be so stingy here?

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: pgp0xrFDjM4GK.pgp
Description: PGP signature

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion@lists.en.qi-hardware.com
Subscribe or Unsubscribe: 
http://lists.en.qi-hardware.com/mailman/listinfo/discussion

Reply via email to