Hi again, The ICA runs for the lfs-alphabetical builds are getting nearly byte for byte repeatable. Here's a really quick summary of what's been done:
* Started off from the 20051216 revision in ~jhuntwork that had mostly been determined by Jeremy and Chris Staub. * Added -Dman1dir=... to perl configure.gnu to allow groff to be after perl. http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055178.html * Added echo '#define YYENABLE_NLS 1' >> config.h to Ch. 6 bison http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055164.html * Moved sed before perl to remove hardcoded reference to /tools/bin/sed * Implemented DIY-Linux toolchain build http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055149.html * Patched farce-001-5 to allow stripping of statically linked binaries http://staff.washington.edu/dbnichol/lfs/farce-001-5-test_static-1.patch * ICA only patch to perl to remove embedded date/time stamp (see below) http://staff.washington.edu/dbnichol/lfs/perl-5.8.7-remove_time-1.patch * ICA only patch to vim to remove embedded date/time stamp (see below) http://staff.washington.edu/dbnichol/lfs/vim-6.4-remove_time-1.patch * ICA only sed to nscd to remove embedded date/time stamp (see below) http://staff.washington.edu/dbnichol/lfs/nscd-remove-time.txt Concerning the last 3 points. These are gross hacks. I only used them to make sure that the differences that were always occuring in perl, perl.o, nscd and vim were truly timestamp related and not build related. Turns out that they were. The above patches and sed's are not intended for the build. (In fact, I'd like someone with C programming experience to look at nscd_stat.c and make sure I didn't break it.) To repeat, the last three steps prove that perl, vim and nscd are repeatable and the differences stem from functions implementing time stamps in the source code. Here are links to the current results. NOTE: I had to move my little repo because I'm getting booted from the student server at Washington. However, I just found out that I have a staff website (graduate school pays off). So old links concerning my alpha work will soon be broken. * Order of the packages http://staff.washington.edu/dbnichol/lfs/lfs-alpha-20060111-reports/scripts.list * Iter 1 vs Iter 2 ICA report http://staff.washington.edu/dbnichol/lfs/lfs-alpha-20060111-reports/ica/REPORT.1V2 * Iter 1 vs Iter 2 Farce report http://staff.washington.edu/dbnichol/lfs/lfs-alpha-20060111-reports/farce/1v2/farce-differ * The build logs with commands used for each package http://staff.washington.edu/dbnichol/lfs/lfs-alpha-20060111-reports/logs/ * My script set that implements all this *hit http://staff.washington.edu/dbnichol/lfs/dbn-build-20060111/ Notes about the results: * These compare very favorably to the ICA set from DIY-Linux http://www.diy-linux.org/~greg/ICA/ * As seen from the reports, perl, perl.o, nscd and vim are gone due to my above hacks. * All the .o differences in the stc++ .a archives are repeatable due to injected randomness in C++ compiled objects. I can't find the link to where Greg talked about this right now. * Config_heavy.pl differs only because -Dman1dir... is only added to the first iteration and this file records what the Configure arguments were. * Differences in the stdc++ .la archives are harmless since the only add extra references to -lm and -lgcc_s. To see the text differences for both of these, look at http://staff.washington.edu/dbnichol/lfs/lfs-alpha-20060111-reports/ica/1V2.ASCII.DIFF * gccbug is probably harmless but could be satisfied by adding mktemp to Ch. 5. http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055157.html * man.conf is equally harmless. /usr/bin/col comes from util-linux, but I don't see a good reason to fix this one. Still to do: * The iteration 1 glibc .a archives still contain references to /tools/include, etc. I forgot to change the Ch. 6 glibc to DIY style which adds --with-headers=/usr/include. Possibly this will clean things up a bit? * Determine if removing some of the DIY toolchain steps will revert the ICA. * Look into stdc++.h.gch stuff. I was under the impression that these would always differ due to the C++ randomness mentioned above. However, they don't differ between the 2nd and 3rd runs. * Reverse the order of the still-alphabetical section of Ch. 6 to determine more true dependencies, e.g. this order doesn't determine whether vim *could* come before gettext. That's all for now. I'll be out of town from Friday to Monday to visit my sister in NYC, so if anyone has any comments, that's why I'm quiet on the reply. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
