Iterative Purity Analysis

Ken Moffat ken at
Wed May 12 12:55:37 PDT 2004

 People with long memories may remember that I harbour doubts of the "is
this anal enough" form about the Iterative Purity Analysis that Greg in
particular posted here.  My regression analysis scripts are now at - at this point,
/very/ crude and awkward.

 People using Greg's IPA tools should note that I look at the details of
what differs in the files, and make attempts to allow common date/time
formats which are found in the base LFS build - any other unexpected
differences are ultimately treated as failures, whether they be in
"text" (displayable 7-bit ASCII) or otherwise.

 The "expected"  differences are listed in a `legitimate' function in
one of the scripts, they're for files which change with bootable systems
on different drives, and for /compressed/ kernel images (just changing
the time in the header shown in dmesg is enough to alter the size of the
compressed binary).  The scripts *will* compare /boot/vmlinux if it is

 This might be useful for anybody researching changes to the build
order.  It also copes with the parts of BLFS that I always build before
I reboot (special-casing .py? files and ssh keys), it can be extended
for others as they come to light.

 Although I've got the proverbial bee in my bonnet about doing a second
full build starting from chapter 5, the scripts are agnostic about this
and should work with the results from using chapter 6 to build chapter
6.  The "benefits" are that these scripts dig a little deeper to show
what is reasonable and what isn't, and do not require the two builds to
be on the smae date.  Equally, just because we can visibly see a
date/time difference in `strings' doesn't mean there aren't other
unexplained and (assumed) undesired differences.  My scripts will find

 The scripts will work cross-architectures with the following
restrictions: (a) we can't strip a foreign binary to decide if a
difference really matters, and (b) the length of the datestamp to ignore
in .py? files is hardcoded at 4 bytes.

 For 5.1-pre2 (using the "old" version of glibc) the following are my
main findings at this point:

(i) a few members of libstdc++ and libsupc++ differ (on both i686 and
ppc).  Not yet understood.

(ii) /usr/bin/flex is an interesting marker for things going wrong (I
accidentally mounted '/' at '/mnt/lfs' and built my second i686 build
over the top of the first.  A few files with small differences  - vim,
lynx, lsof - and /usr/bin/flex was about double the expected size).

(iii) within the logs (for chapter 6), bash has fewer "banners" the
second time around, and in flex (on a "good" build) some of the
compilation lines move to different places in the log.  There are also
occasional "gratuitous" additions of the "nothing to be done for
check-am" type in the second build.  These are just curiosities at the

Instructions in the tarball, or mail me off-list (but don't blacklist my
cable IP address if you do that!).  Share and Enjoy!

 das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list