[Techtalk] question re: compiling/installing binutils stripped

Almut Behrens almut-behrens at gmx.net
Tue Sep 28 23:11:28 EST 2004


On Tue, Sep 28, 2004 at 12:25:56PM -0700, Darlene Wallach wrote:
> I've been downloading, compiling and installing the software
> and versions of software required for gcc-3.4.2
> 
> After installing binutils I started making sure the new
> versions would be used under /usr/local/bin vs /usr/bin
> I noticed the new versions were not stripped. I looked
> at configure and Makefile to look for an option to
> compile/install stripped. I have not found what I need
> to tell either configure or make so I get a stripped
> version.

It's probably easiest to just call strip on them, i.e. 'strip <binary>'.
(BTW, never tried what happens if you call strip (being part of the
binutils) on itself -- so you might want to use the old one for that.)

If you want to build the tools directly without debugging symbols, you
should make sure that -g is _not_ in the compiler options supplied.
Most autoconf-generated files use something like CFLAGS or CCFLAGS in
the makefile.  If you set this variable in the environment before
starting the configure/make, you can supply your own compiler options. 
Those typically override the internally determined ones, so make sure
the original options remain in place (everything except the -g).  For
this, just run the build once without modifying the options, to see
what options actually are in effect, then cut-n-paste and modify
them... (removing the -g in your case).
(You see why I said it's easiest to use strip ;)

> 
> Is there a reason I would want the not stripped version
> if I don't plan on debugging the binutils?

Normally not. If you really want to debug the tools themselves, you can
always rebuild them with debugging symbols.  OTOH, it's also not a big
issue leaving the programs unstripped (except if you're very short of
storage space) -- there's no noticeable difference in performance (one
might argue that smaller binaries load faster, but modern OSses can
handle this quite well...).

Cheers,
Almut




More information about the Techtalk mailing list