Unusual results in regression testing

Kelledin kelledin at users.sourceforge.net
Wed May 15 10:54:09 PDT 2002


> I had thought that the files were getting smaller in the second build, but
> I was mistaken. They were actually abnormally large in my first build! My
> host system is, I think, LFS-3.0, so some of the packages are out of date
> (particularly vim, glibc, ncurses). What seems to be happening is that the
> chapter 5 static programs use the libraries from the host system (they
> have to), but the chapter 6 programs which are installed before gcc
> (glibc, findutils, gawk, ncurses, vim) seem to also use routines from the
> libraries on the host.

One thing I noticed--when using gcc -O3 vs -O2, the final, dynamic 
executables come out quite a bit larger with -O3.  This is presumably due to 
optimizations like loop unrolling and function inlining--which make execution 
faster (assuming everything fits in system RAM) but makes code size larger.

> 2. A lot of the glibc binaries are slightly bigger when I install them to
> /usr/local. I'm guessing that `strip --strip-debug' is not aggressive
> enough (no, I'm _not_ talking about libraries, but about programs such as
> gencat.) Typically the difference is an exact 10 bytes more.

Also, some things I've found about stripping things:

1) Binaries can be stripped completely.  So can dynamic libraries (.so 
files).  The only caveat is not to go stripping such files while they may be 
in use; the best way to avoid this is to strip them as soon as they are 
installed.  The common "make install-strip" rule, when present and working, 
will always strip binaries, but only sometimes will it strip libraries.

2) When building RPMs (ick) within a build root, binaries will be fully 
stripped automatically, but libraries might not be stripped at all unless the 
Makefile or spec file includes the necessary strip commands.  rmp's 
auto-strip steps do not get performed if a build root is not used.

2) Relocatables (.o files) and static libraries (.a files) can only have the 
debug symbols safely stripped.
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list