--- In [email protected], Alessandro Rubini <[EMAIL PROTECTED]> wrote:
>
> 
> > sudo /usr/local/cris/cris-strip --strip-debug libstdc++.a
> > sudo /usr/local/cris/cris-strip --strip-debug libc.a
> 
> Actually, since static libraries are built to ease debugging,
> stripping it is not usually wise. If you need the information,
> it is lost.
  
I second that.  But I'm stripping those libraries for (at least) 3
reasons:

1. Already mentioned: my app became way too big

2. I'm fully confident that libstdc++ and libc are fully mature. 
They've been tested already a tig times by many millions of people, so
there's no need any more for me to keep the debug information into
those libraries

3. I have to statically link libstdc++ into my application, because
it's not part of the RFS which is flashed into the FoxBoard (mine is
still the "old" MCM, being 4MB flash, 16MB RAM).
It's not part of the RFS, simply because if it would be part of the
RFS, the complete image (kernel + RFS) would not fit any more into
that 4MB flash.

> > When building statically (the way I do it), the results are really
> > very positive.
> 
> When building statically, parts of the library are copied in your
> application. So you should strip the application after the linking
> phase, without touching the installed libraries used by the linker.

Well, if I'm stripping my application *after* the linking phase, also
the debug info needed to debug *my* application would be gone, isn't
that so?  If yes, than that's not an option for me since I want to be
able to debug my app.

> > Finally, my app dropped from 7645244 bytes to 1964781 bytes.
> 
> You can still strip it, as you didn't remove extra info from your own
> code (only from the library).  Or you can pass "-s" to the compiler
> command line to strip it while linking.
 
Didn't know this option, thanks for sharing.  But again, if I do this
then I'm kicking out the debug info of my own app too, am I right?

> To see the real size of an application, use "size" (or "cris-size"
> if you lack the binutils-multiarch package).

Another one I was not aware of, so thanks again...

Best rgds,

--Geert


Reply via email to