Unusual results in regression testing
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