On 8/4/07, Ken Moffat <[EMAIL PROTECTED]> wrote: > On Thu, Aug 02, 2007 at 11:34:23PM +0100, Ken Moffat wrote: > > > > Anybody who follows my ramblings on clfs-dev will know that using > > an earlier kernel than the headers, particularly an -rc kernel, is > > "NOT a Good Idea" (TM) and I'm lucky I wasn't using glibc-2.6. > > > > I'll try to do a fresh by-the-book pair of builds (without > > non-toolchain tests) if I've got time. > > > I rather wish I hadn't bothered! This was 2007-07-31 with > glibc-2.5.1. The following files differed: > > /lib/libc-2.5.1.so > /usr/bin/perl (also flagged as perl5.8.8 which is a hard link) > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/cc1 - generally expected > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/cc1plus - generally expected > /usr/lib/libstdc++.la - known difference > /usr/lib/libsupc++.la - known difference > /usr/share/doc/groff/1.18.1.4/meintro.ps impenetrable difference in numbers > /usr/share/doc/groff/1.18.1.4/meref.ps impenetrable difference in numbers > /usr/share/info/coreutils.info - known problem, second build used precompiled > info
Using jhalfs and farce (no compiler options) I got good results: $ cat iteration-1_V_iteration-2/farce-differ /etc/blkid.tab.old /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/cc1 /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/cc1plus /usr/lib/libstdc++.la /usr/lib/libsupc++.la /usr/lib/locale/locale-archive /usr/share/info/coreutils.info For some reason, the TIME changed for all my volumes in blkid.tab.old. Don't know why. I'm also not sure about locale-archive, but I'm not worried about it and I recall Greg used to see this issue, too. > Of these, the libtool archives add, or rather repeat, directories > in the first inplace build - libtool is like that, not a significant > issue. cc1 and cc1plus seem to differ for everybody, they should > probably be treated as 'expected to differ'. Yeah, cc1 and cc1plus will differ unless you strip the objects before they're linked. I.e., LDFLAGS=-s or CFLAGS!=-g. The reason is that essentially a hashsum is taken of the objects to be linked into cc1. This is then compiled into cc1. If the objects contain debugging symbols (the default), the hashsum will be different between the first and second passes since the location of the crt files changes. This hashsum can't be stripped out later because it's part of the program data, not in a .debug section or something. > The postscript files are impenetrable, the differences are in long > strings of numbers - this is the first time I've run farce on this > version of groff and I suspect these numbers are calculated, and > there is a small amount of error. I'm not worried about this. I don't know why you get those and I don't. > That just leaves two somewhat important binaries. Looking at <snip> > -libc-2.5.1.so-0: file format elf32-i386 > +libc-2.5.1.so-1: file format elf32-i386 <snip> > -perl-0: file format elf32-i386 > +perl-1: file format elf32-i386 I applaud your efforts to debug these differences, but I see nothing. Usually, the only way I've ever solved these things is at the source level. E.g., stop the build at perl round 2 and try to figure out what's different before generating the binaries. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
